I will start by providing you with great resources for MVC design. The first is the WWDC 2010 Session 116 Model-View-Controller for iPhone OS (really just iOS), it is slightly tailored to the iOS classes, but gives a lot of generally useful information too. You have to register to be an Apple developer (free) to get access to it. The second is the publicly available Stanford iOS course, again it will be tailored to iOS, but his introduction class focused on MVC in the general sense.
Ok, so what you get from those resources are rules such as Views don't own the data they display.
Straight from the Stanford course:
Model: What your application is (but not how it's displayed)
Controller: How your model is presented to the user (UI Logic)
View: Your controller's minions
Controllers: direct communication to models and views.
Views: "blind" communication to controllers (target-actions and delegation). No communication to models.
Models: broadcast communication to controllers (Notification and KVO). No communication to views.
For your specific case, I'm not sure I understand what you're describing 100%, I'm not sure what those "widgets" are (at least for Android, a widget is a bundle of MVC(s) that provide some functionality like a search bar widget). But if you mean that the ListModel is something like a title and implicit index, and the DisplayModel is a matching description for the given index, then I might have a MainController (for the main view that is containing these two subviews or fragments). The user selects an item in the ListView triggering some sort of onSelection function on the MainController (now the MainController knows what item they selected). The MainController passes that along to the DisplayController (now the DisplayController knows what item they selected). Finally, the DisplayController can use the DisplayModel to find what needs to be displayed now and then tell the DisplayView to display it.
Alternatively the DisplayController can respond to the onSelection function triggered by the selection in the ListController directly, but that connects components that probably shouldn't be connected. Because you said they were their own Views that means it could be possible to have a set up (possibly for smaller screens) that had the ListView on the full screen, a selection is made, then the DisplayView takes over the screen showing the description of the selection made. For that reason I would leave the views separate.
So, let's start by saying MVC is just a guide to producing nicely structured code, as far as I know it isn't strictly enforced. Next, for the "non-canonical" refer to what each component is suppose to do.
Essentially everything that isn't written to display something or interact with the display is part of a model. Models are the algorithms that perform tasks. Views are only to surface a UI, and provide ways for the program to interact with the UI (as in the target-action connections and delegation). This leaves the Controllers to be the delegates and targets for the Views. Think of the as kind of the gears under the views I guess. They should be the link between actions on the screen and functions and data in the Model. They should make sure the Views display the content you want to be displaying.
Here are pictures taken from the Stanford course (the first class) that show how and how not to set up multiple MVCs. (unfortunately I can post a maximum of 2 hyperlinks and no images)
MVC done correctly
MVC done incorrectly