The Model (collectively) is the actual state of the world. There is one true world state; there can never really be more than one. So yes, use one model which consists of one sub-model for each unique element in the world.
In the real world, the "model" or state for your backyard might state that there are 7 puppies there; no more, and no less -- there is no ambiguity, because there is only one true "state" of your backyard (ignoring quantum mechanics :)
Views are representations of the world. A thing can be represented in an infinity of different ways. For instance, your puppies might be represented by nametags which give them each a unique name; they can be represented by photographs of each individual puppy; they could be represented each by their own unique DNA (as an alphanumeric string); or each puppy could even have a unique theme tune associated with it. So you see there are countless means of representation; as many, in fact, as you care to dream up.
A good example of using multiple views for the same part of a model, in a game, is the main world viewport vs. the minimap which many games have. In a minimap, each entity is represented as a small icon (Elder Scrolls) or even a pixel of a particular colour (StarCraft), whereas in the world view they might be 3D models or full sized, animated 2D sprites.
So the number of "views" is determined by looking at how many ways a particular thing needs to be represented, within the bounds of your design. But the relationship between model and view is always 1:n, where n can theoretically be anything from 0 to infinity.
Feedback from sprite to associated model
This is usually done through a publish/subscribe model, commonly found as event dispatcher / listener pairs. So when the sprite view object is moused over, clicked or whatever the case may be, it will dispatch an event which will trigger some update in the game logic -- which thus affects the model.
But if you wish to keep things simple, and bend the rules of MVC a bit, you can just give the view a direct reference back to the model. That's not good encapsulation, but it is much simpler / more direct to set up.