I have run into this problem of Excel destructively manipulating CSV files. The truncation of leading zeros on numbers was probably the most frustrating event.
I am having difficulty locating the information on the Microsoft web site, but I recall that when opening a CSV file, Excel looks at the first 50 rows and does a best guess on the appropriate data type of a particular column. This is why the leading zeros get truncated from numeric-looking data.
My recommendation is to avoid the use of CSVs in any workflow where users of any kind could open to edit data and/or open to confirm data. In my opinion it is far too easy to open to edit or confirm a CSV file in Excel rather than a text editor. Any processes downstream after an Excel edit could either have invalid inputs or cause the process to break. Any open to confirm data in Excel can yield the wrong view of the data contained within the CSV, plus the tendency to want to edit and save the CSV in Excel is great and should be avoided.
Jeff Parker's recommendation of using XML is a very good one. For earlier versions of Excel, the *.xls file extension is actually several different document type formats, including binary and most importantly xml. The xml-flavored *.xls file allows for the defining of column data types and additional formatting. For Excel 2007 you can get more information here: http://msdn.microsoft.com/en-us/library/aa338205.aspx
Bottom Line Suggestion: If you must use CSVs (XML or fixed length is not an option) in some workflow then I strongly recommend *never* opening them with Excel. If you must allow for user editing/confirming of the CSVs then I recommend not allowing access through the file system (and thus Excel) but rather through a WinForms or ASP.NET application or another abstraction.