Your second and third bullet points seem correct to me, as long as you don't do any logical stuff in your model from your views. The link between models and views must be read-only.
Concerning your first point, you don't need to assign anything to the view, you view helper should return
your HTML output directly to the view.
About your first question, you could create View Helper that is specialized in this task, so you can use it as a simple proxy between your view helpers and mappers. One view helper will allow you to access to any mapper, and others view helpers can use this view helper to get a mapper.
Let's see what Trygve Reenskaug thinks about MVC:
Models
Models represent knowledge. A model could be a single object
(rather uninteresting), or it could be some structure of objects.
There should be a one-to-one correspondence between the model and its
parts on the one hand, and the represented world as perceived by the
owner of the model on the other hand.
Views
A view is a (visual) representation of its model. It would
ordinarily highlight certain attributes of the model and suppress
others. It is thus acting as a presentation filter.
A view is attached to its model (or model part) and gets the data
necessary for the presentation from the model by asking questions. It
may also update the model by sending appropriate messages. All these
questions and messages have to be in the terminology of the model, the
view will therefore have to know the semantics of the attributes of
the model it represents.
Controllers
A controller is the link between a user and the system. It provides
the user with input by arranging for relevant views to present
themselves in appropriate places on the screen. It provides means for
user output by presenting the user with menus or other means of giving
commands and data. The controller receives such user output,
translates it into the appropriate messages and pass these messages on
to one or more of the views.