"Serialization" is what occurs when binary computer memory is converted into a format that can be transferred to disk or over a network connection. In Salesforce (and most other web-based platforms), this is commonly called the "view state". The view state contains information about the memory contents of variables. When a Visualforce page receives a view state, it "deserializes" the data into an existing object, and acts as the object initialization routine (instead of the constructor that is defined for the class). When there is no view state, the constructor is called instead. In any event, all items that will be stored in the view state are gathered up, and converted to a format that can be used for the next view cycle. All remaining items will be effectively discarded forever when the page is done loading.

Here's an outline of a Visualforce page cycle:

1. Receive request to load a Visualforce page.

2. Attempt to deserialize the view state, and if successful, go to step 4.

3. Call the object's constructors.

4. Call all "setter" methods for submitted data.

5. Call any "action" method that was called.

6. Call all "getter" methods for the page's output.

7. Serialize all of the data needed for the next page view.

8. Render the page.

9. Commit all transactions to the database.

10. Release all resources associated with the request.

Of course, I'm over-simplifying the entire process with such a simple outline. However, the illustrative point here is that every Visualforce page load starts at step 1 and goes through the entire process (assuming no faults, aborted page loads, etc). Note that the order isn't necessarily "exact" either (after all, I'm just an outside developer), but it's just an illustration. Serialization and deserialization in the Force.com platform is based on the java.io.Serializable interface in Java, so you might read more on that for details. 

Now, here's the important part of what it means to be serializable: some data constructs can not possibly be valid over a single page view, and thus can never be serialized, because they would not work. The notable case is the Savepoint object, which allows you to rollback pending transactions in the event of a business logic error. Transactions have to be committed or rolled back before the process that is rendering the page completes, because the connection to the database is severed at that point (as far as that process is concerned), so it would have no way to retrieve a save point from a prior process.

Additionally, records that are held by a save point can't be updated until they are committed or rolled back, so a page that could hold a transaction indefinitely would cause headaches for other users trying to edit the same record. Even worse, if that could happen, the user could cancel the process by, for example, closing the browser, and those records would be deadlocked until some inactivity timer expired.

The keyword "transient" is used to describe a variable that will explictly not include itself in the view state, and should be used for all global variables that do not need to persist between page views. They are effectively reset to "null" each time the page is loaded. Transient variables reduce the total size of the view state (which has a governor limit attached to it), and is useful for variables that have no meaning between each page view.