Question: I'm just starting, and yes, i haven't written any tests yet (I'm not a fundamentalist, I don't like compile errors just because there is no test), but I'm wondering where to get started on doing a project that parses fixed length flat file records according to an XML mapping, into a class that represents the superset of all file layouts, before writing (with transformation) the class details to a DB table.

There are so many external factors, and I don't want to mock them all, so where or how would be a good way to start test driving this project?

Answer: 
It's all about decomposing the problem into parts. Some examples:

* File/stream reader
* Input mapper
* Input mapper loader
* File layout
* File layout collection
* Data access layer

Try to give each class a single responsibility, determine its dependencies, and inject those in. That, with the help of mocks/stubs, will permit you to test each class in isolation.
Two techniques I've found useful for testing IO-based classes:

* Where possible, talk in general terms like `StreamReader` and `Stream` rather than filenames. It's easy to create a `StringReader` or a `MemoryStream` in tests and provide the data that way.
* Sometimes you need more data than you really want to embed in literals in the code. In that case, add test files (sometimes both input and expected output) as embedded resources, and use `Assembly.GetManifestResourceStream` to get the data at execution time.

Beyond those general points, TrueWill's advice sounds very good. If you can split up the bigger task, writing the unit test for each individual bit sounds like it'll probably be easy - with the exception of the database access, which is usually a pain. If you can make the database part as small as possible, providing all the data from another easy-to-test class, that should make life simpler.