Session state should be orthogonal to domain state. You most likely want to keep your session state in your view layer, and keep your service/domain layer stateless if at all possible. This means you will need to pass any user information into your service layer from your controller.
If this becomes an issue, and you need long-running session state, externalize it to a separate store, and link it to the passed in session information. This keeps the "session" for the domain layer separate from the "session" in the view layer. Thus preserving the abstraction between model and view.
You will start incurring business logic bleed into the view/controller layers, as the session state is much more conveniently located there. Be aware of it, and work to control it.
The MVVM pattern might fit this a lot closer than MVC will, and it does a better job of encapsulating the view state on the business server side. Sessions are still at issue though. You will need/want separate sessions on the view / business layer, but the one on the view layer ends up being very light. It basically just needs to handle authentication, and then have a key (sessionid) which it can pass to the service layer to allow the viewmodel to link up with.