In this case, the "RegDate" would only be input on the Info Path form and saved to flat file (source). From the application end, the users would only be generating reports that have an extra column showing "RegDate" but no means for changing the value, nor any need to do so. So I don't see a concern about data drift for this reason. Keeping the target database table (with the new "RegDate" column added to it) up to date (since the SSIS package is used in a nightly job) would be a potential issue. But if the users make a habit out of pressing the "import regdate data" button from the app (which I'd add) to pull the latest data from the flat file just before they wish to generate reports that require the target db table to have the updated data, I think it should be ok as a stop-gap measure.
The only thing I foresee as a potential issue is that the SSIS package performs the necessary joins and associations already, so in my case simply enabling "RegDate" as another column would have made the final solution simpler than the stop-gap measure I may have to come up with. I'll have to find another relationship between "RegDate" and the record id representing the corresponding class the user took. Since the flat file does not contain the unique record ID, all I have to go on is transcript/course completion date.