The template for the main view, or the subview that can hold modules,is structured in such a way to have a .container to append my modules into.
The main view is usually rendered only once and behave as a proxy for the various modules relying to the events.
The great benefit form this approach is that it's quite easy to maintain/replace a single module as long as the events api don't change.
second is i actually define the sub views element from the parent view on instantiation, and operate under the assumption that all subviews will render by emptying their element and replacing it's contents. the primary reason is so the root subview element never changes (which can lead to complexity).
About the models I prefer to use an unique one for maintenance and team development cause it's harder to accidentally break things.
It's just a question of how small you really want subviews to get. I personally don't think it's beneficial to have a single label be its own view. Especially when you could have many many inputs on a page.
but breaking apart your render method is only one way to achieve this. using a sane layout manager with subviews is my preferred approach (though i suppose you could argue this is just breaking up the render method across several views). this technique is also admittedly a pain at small scales.
the beauty of this technique, though, is that every view is responsible for it's own rendering. that is, parent views don't need to be aware of the re-rendering process of their subviews (how or when). another great benefit is you will find yourself referencing items by selector less often, and instead through the subview's element.