I’d say you’re on the right track but I’m wary of making “one size fits all” statements about where things should be done.
What you’re describing is the Model View Controller pattern (MVC) which concerns itself with the separation of responsibilities.
View is what you see - Buttons, Labels, etc.
Model is the business logic, data access, algorithms etc
and Controller does the coordination between the two.
So if a button is clicked to save a record. The View will notify the Controller that the button was clicked and the Controller will tell the Model to save the record. If you then want to change the View to use for example, a gesture instead of a button, then only the View will need to be changed. Or, if you wanted to replace your local database with an iCloud version then only the Model would need to be changed. By separating these responsibilities it makes an application easier to maintain, more flexible and also helps take advantage of code reuse.
Apple refers to two versions of MVC in the Cocoa fundamentals guide. The Cocoa version, where the View and Model don’t know anything about each other and all interaction is via the Controller, and the traditional version where the View can also interact directly with the Model.
So whether you should instantiate Model objects in the View or the Controller would depend on what your application does and what it might do in the future. If the View is purely representative of the Model then it probably wouldn’t hurt to get the data directly from the Model (which is the traditional MVC pattern). If the View was more generic though - say a graph - then it may be better to have the Controller communicate with the Model and then pass the data to the View (Cocoa version). If you look at UITableView the core functionality is View-based, the Model elements are implemented via the dataSource and the Controller functionality is provided by the delegate.
You will also see View and Controller functionality collapsed into one class – xxxViewController and even when the class designers have segregated the functionality it’s perfectly acceptable to collapse it back into one class ([self.tableView setDataSource:self] in certain situations.
So when designing an app and making decisions about where to instantiate objects I would suggest thinking about whether the particular class can be reused elsewhere, can it be designed in such a way that if something changes the code impact can be minimalised, can it be built in such a way that requires less direct coupling with other classes to operate. I find it helps to sketch out class diagrams and visualise the interaction before you start coding.
If you have a developer account I would recommend the WWDC 2010 video Session 116 Model-View-Controller for iPhone OS. There is also a lot of great info on patterns in the Cocoa Fundamentals Guide.