No viewstate. No server-side controls. Think RESTful/stateless; it's a request/response cycle, not an event being handled.
It's worth consideration to take a side trip into Ruby/Rails to learn the concepts completely outside the .NET stack before you tackle MVC. I know that I was able to pick it up pretty quickly because I had already dabbled in Ruby/Rails enough to be familiar with the paradigm.
EDIT: I would also add that I find that separating view models from business models (entities) is a good idea. You should definitely be using strongly-typed views and passing models around rather than passing "untyped" ViewData to your views and pulling "untyped" data from the request or value providers directly. Using models and making the model-binding framework work for you will make it much easier both to test and keep your views cleaner. Using strongly-typed data in your views will at least give you some compile-time checking there as well.