I think one of us is missing something important. I understood your goal to be the separation of your existing monolithic database into 2 separate entities - one for local data that would be updated rarely (if ever) and used for general application purposes (beautification, lookup, rules, etc.). The other database would be centralized and used to store "transaction" information. Once you decided to separate the data, it seems to me that you will have no choice but to "write a data acess module to arbitrate ..." since you can no longer join to it directly or indirectly (via standard DDDW behavior).
Regardless, you can create a DSN to a csv file by running the ODBC administrator and creating one - the list of drivers I see include the "Microsoft Text Driver (*.txt; *.csv)". I wan't recommending this approach - just noting that it could be done. And keep in mind that a transaction object can only connect to a single file at a time AFAIK. Now that I think about it, you should also be able to do the same thing with an excel file - storing each table in a sheet or named region (or whatever the correct term is now).