That comment was made by me as an offhand remark; it was probably too handwavy, so I better elaborate on it a bit. The problem is that both use the same terms and similar high-level concepts, but there are certain non-trivial differences.
From a historical perspective, (classic) MVC came about in a language called Smalltalk, in the late 70's and the 80's. Today, various UI libraries/frameworks provide you with ready-made controls (a.k.a widgets1) - buttons, check boxes, radio buttons, sliders, scroll bars, text boxes, etc. These can detect events like clicks, button presses, and have various other capabilities like data binding and whatnot. Back then, that wasn't the case - all those were just pictures on the screen. So people came up with a pattern: each widget would be made out of a View - an object that would render it (combine visual elements and display it), and a Controller - an object that would detect and interpret user input, turn it into a command of some kind, and invoke some domain function within the business logic code, and instruct the view how to adjust itself afterwards. Generally, each view would have some piece of the business logic associated with it. This piece of the business logic - some class or a group of interacting objects - is the Model associated with that view. So the Model is not a data structure, it's a business object. It's also not a model of the view (as in "view model"), that's something else. It's just an object that implements a part of core application functionality (what the application actually does). So in the original version of MVC, each button, text box, check box, etc. was made from its own MVC triad.
Now, over time, widgets became smarter, applications got bigger, and the pattern evolved into what we know as the MVC/MVP pattern today (the P stands for "Presenter"). The View is now more complicated - it's some kind of a specialized panel, or a form, or a screen, usually composed out of a bunch of more primitive widgets (buttons, labels, text boxes). The View is still really about rendering, but it now has more advanced capabilities - you can do things like subscribe to events of a particular button, or adjust a layout by altering a property, etc. The Controller is still about interpreting user input, interacting with the model, and governing presentation logic, except some of the more generic view-related behavior is now left to the view.
The whole idea is to separate presentation logic from the business logic. The presentation layer contains a bunch of view-controller pairs, and the business logic layer is unaware of their existence - models don't know about (don't depend on) views and controllers.
There are several variants of the pattern; in some the View contains a bigger chunk of presentation logic, in others nothing but the very basic stuff - it just knows how to draw itself, and all the manipulation (what's enabled when, what should change color under what circumstances) is placed in the Controller or the Presenter. These variations are driven by different concerns, testability being one of them.
Now, one variation of particular interest (in the context of this answer) is called Presentation Model. There, the idea is to represent a view in an abstract way, independently of the GUI framework used, by basically putting data that represents various aspects of the View into the Presenter (or a closely related class - the Presentation Model), and manipulating that data, rather then the View itself. The view is then updated by some synchronization mechanism, like data-binding. GUIs developed in .Net with WPF are organized around this pattern, but in that context it is called Model-View-ViewModel (MVVM). Here, the Model is still the what it used to be (the code that does the actual work of the application), and a ViewModel is the Presentation Model - an abstract representation of the view that resides in the presentation layer.
Finally, we arrive at Web MVC. There's a bunch of web MVC frameworks that are designed around an MVC-like structure. This is all happening server-side. Here, views are "rendered" to HTML and sent back as the response to a web request. So a View here is less an actual view, and more a thing that knows how to construct a page; this is usually done via some sort of HTML templating engine. There are often "view models" involved, e.g., they are commonly found in ASP.NET MVC. But these are just plain data structures that are passed to the view, and not ViewModels in the sense discussed above (and they are most certainly not Models (the M in MVC), although some people seem to think so). BTW, I'm not saying that's bad, just that it's different. The Model, as before, resides in the business logic code of the web application. Also, in Web MVC, you can't really ignore the fact that it is happening server-side and that the view will be transferred back over the web, and this puts certain constraints on the way you implement things. The cadence of the interaction is also different, and is dictated by the request-response cycle. So, as I've said before, it's a bit confusing because the high-level concepts are the same, but there are aspects that differ, and the terminology is slightly different.
The core characteristic of MVC is the separation of the presentation logic. Keeping that in mind, another thing worth pointing out is that using these web MVC frameworks doesn't make that automatically happen. So choosing a framework does not in itself amount to choosing an architecture; rather, MVC is a pattern that's applied by the developer team in order to achieve said separation. If you are not deliberate about this separation, you'll end up with a tangled mess of dependencies, with some of the business logic in the controllers, and some of the view-related code in the business objects. Unfortunately, a lot of the examples on the web lean towards that kind of code.
There are also client side (JavaScript) MVC frameworks, but the roles various MVC components play there are more in line with the MVC/MVP UI pattern, it's just that the execution environment is the browser.
1 For this particular discussion, I'll prefer the term "widgets" rather then "controls" in order to avoid potential confusion with "controller".
