ViewModels are great for when your model entities do not correspond one to one with what you want to show on the screen.
A simple example is an application that stores information about people. Imagine your domain model has a Person entity and an address entity. Each person has many addresses but one default address. In one of your views you want to show the Person's details as well as the details of their default address. If you want to keep your views strongly typed against a model (which you should) that would be impossible as you can not type a view to 2 entities.
Here is where viewModels are at their best. You create a new viewmodel class that has 2 properties one of type person and one of type address and in your controller you fill those properties with the needed information and you type your view against this Person+address model class.
As for the code for them they are just like any other model. An example is coming shortly.
Domain Models (found in your data access layer maybe, or in a seperate domain model project):
public class Person{
public int PersonId{get;set;}
public string Name {get;set;}
.
.
.
}
public class Address{
public int AddressId{get;set;}
public string Street1 {get;set;}
public string Street2 {get;set;}
.
.
}
Then you can have a viewModel class like so:
public class MyViewModel{
public Person ThePerson{get;set;}
public Address TheAddress{get;set;]}
}
Or even
public class MyViewModel : Person{
public Address TheAddress{get;set;]}
}
But I prefer the first solution while a colleague chooses the second one regularly. Your views would then be strongly typed against MyViewModel and the values accessed in the view through syntax like: @model.Person.PersonId