Maybe it'll help to explain it differently:
A Model is a collection of data and the structure of that data. A couple of examples: say you have a list of names in a text file. The names is the data, the fact that each name is on its own line in the text file is the structure. The more obvious example is a database: the entries are the data and how the tables are set up and connected is the structure.
A View is the UI and how the data is presented to the used. This is the buttons and rows and other visual elements that show up on the screen, along with the code to pass input on to the controller. Think dumb terminal; the View doesn't know what the data is, it only knows that it's going to display 10 rows of something it recieves from the controller and if the user hits the next button, it should tell the controller about that.
A Controller is what parses the data from the Model and prepares it for the View. It's the middleman between the View and the Model. The Model doesn't care how it's data is presented or even if all the data is used, it's fairly passive. The View doesn't care what the data is, only what fonts or screen regions are going to be necessary to show it. The Controller is what takes the View's input, finds the appropriate data in the Model, and gives it back to the View. The Controller is like a waiter; you (the View) point to an item on the menu, and the waiter gets that item from the kitchen (the Model). You don't care how it was made in the kitchen or what sort of maze the waiter went through to get the dish; you only care that the correct item was given to you.
The Controller is seperated from the Model because you should be able to change the data without affecting how you retrieve/filter it. The View is seperate from the Controller because retrieving/filtering data has no affect on HOW it is presented, only WHAT is presented.
To use a more concrete example:
This is a screenshot from PokeIndex 5th Gen, an app I made for iPhone. The Model in this case is a literal database with the Pokemon's number, name, and filename of the image. The View is a table view: it doesn't know or care what Oshawott is, only that it has to display a 32x32 image, format a 3 digit number with the Marker Felt font at 20 point size, and do the same for a text string. It also has to be pass to the controller a message if any of the rows are tapped. The Controller handles loading the Pokemon info from the database, filtering it (by Pokemon number in this case), and preparing the info in a way the View can use.
I could change the Model to use Pokemon X and Y instead of Black and White and that won't affect the Controller. I can change the View to display a grid of Pokemon instead of a list and that won't affect the Controller. This is the encapsulation that the MVC pattern is designed for. But unless you have a certain degree of complexity in your Model (in this case, it's 650 Pokemon with all thier stats and locations), then the MVC pattern is over abstracting, as blewisjr said. If your View has constraints that keep it from changing, MVC may not be the best solution either.
That said, the iOS libraries push the MVC pattern pretty hard, so that would be one way of immersing yourself in it.