“Perhaps a dynamo script with that was constantly running with both models left opened…”
That’s exactly the kind of performance degradation i think you want to avoid. Working in Revit = modifying elements. So basically, after every worthwhile action you take in revit, you will have to wait a second or so while Dynamo “updates” the time/date stamp for the element (s) that changed due to your user action. In other words - for each transaction you do, you must then allow time for Dynamo to do one transaction that reflects your transaction.
I’m not saying it’s impossible (because I don’t know enough to say absolutely that it is), but is it practical to use Dynamo for this? Probably not. In order to do what you are asking - the majority of the Dynamo definition will likely end up as Python Script since the Updater stuff is not built into any node. At that point, why not just go all the way into Revit Macros and write a Python tool that is always running in the background that does exactly what you want and keep Dynamo out of it? The reason I think that this all may be impossible to do in Dynamo because use of the Updaters usually involves assigning each Updater a GUID through the Code Editor (SharpDevelop , Visual Studio, etc) and as far as I know this is not possible to do in the Python Script within Dynamo.
What you can do in dynamo is take a step back from the second-by-second change-tracking and compare yesterday’s model to today’s model. It would not tell you who did what, but it would enable you to know what changed on what day (and perhaps even keep a record of how the element changed - position, family type, etc). This would likely come close to the first request.
For the parsing of journal files - i’m sure this would be possible as they are simply text files. You’d just need to know what you were looking for (easier said than done).