I'm using the following method to create tables in Windows Azure. This code is executed only once when the application is first initialized
TableStorage.CreateTablesFromModel(typeof(customDataServiceContext), account);
If I have updates (ex. new columns) that I want to make to the table, how do I go about making those updates without losing the existing data?
Just update the CLR classes you use to represent your entities with the new fields. The table service itself is schemaless, so the only thing it cares about is the name of the table, which is the name of your CLR type.
You don't need to call CreateTablesFromModel again, since the table already exists. If you add new tables, however, you do. Your old tables will not be affected by this; tables that already exist are left alone.
Retrieving entities that are already in your tables will result in a null value for the new columns.
Rik correctly mentioned the most important concept: Azure Table Storage has no schema. As far as the storage system itself is concerned, you don't need to do anything if you want to change what you store in the entity set (table). Of course, if you've stored entities (rows) with different schemas, your business logic will need to be prepared to handle the differences. For example, you may need to handle a null value or even different data types depending the changes you've made.
It follows, then, that the system simply needs to know about the existence of an entity set (table) and doesn't care at all about it's contents. This is why there's no requirement to call .CreateTableFromModel when you decide to alter the schema of the entities you're storing.
In my opinion, the Azure folks confuse developers by using the term 'Table' when they really mean 'Entity Set'. Table leads developers down a familiar mental path with fixed schemas and columns. You really should think of an entity set a container of entities (property bags). The only enforeced requirement is that each entity must contain properties for PartitionKey, RowKey and ModifiedDate (?).
ONE FINAL IMPORTANT note is that everything I said is true for the actual Azure Table Storage facility in the cloud. The current implementation of developer storage is a local simulation of the cloud built with an actual SQL database. This means that, when using development storage, you will be restricted to actually use a fixed schema for your entity sets. This is a significant lacking in the development storage's simulation of the real thing, and it's a bummer.