There are two problems to consider:
- How do you review such a commit?
- How do you attribute it?
It is clear that the commit will be so massive that it is practically impossible to review. What you should do instead is use an automated tool to make the change, and put the exact tool used, the version number, and the configuration file / command line arguments into the commit message. That way, everybody can check out the old version of the code, run the tool, and verify that the output of the tool is identical with the new version of the code.
This already allows you to verify that there are no functional code changes hidden inside the massive commit.
And verifying that the style change didn't break any code is now shifted from having to review the massive commit to having to review the quality of the tool used, and that the configuration and command line arguments are correct.
If you have good test coverage, you can temporarily duplicate your tests and your code, so you have two copies of the test suite (one in the old style, and one re-formatted) and two copies of the production code. Then, you run all four combinations of test suite vs. production code. All four results should be identical, then you can be reasonably sure that the re-format broke neither your tests nor your production code.
For the second problem, there is unfortunately no better solution than what you and Robin already proposed: create a special user and attribute the commit to them.
You could get fancy, and try to break up the commit so that you attribute every re-formatted line to the author of the original line, but there are several problems with that:
- What if, during re-formatting, two lines of two authors get merged into one?
- What if, during re-formatting, one line gets split into two?
- It is actually a lie, because that person did not write that piece of code, a program did.