I don't like it*
The phrase "it's not appropriate to have a constructor with this many fields" makes little sense to me. There is no possible way to prevent the creation of some piece of knowledge that works with 500 fields, because you need to work with 500 fields. Whether they are all passed into a constructor, put into a container and passed into the constructor, or handled in a factory method/class has no real effect on the underlying needs of the system.
I call designs like this "moving the problem" rather than "solving the problem", or more broadly, "design by aesthetics". Fundamentally, you don't really have a problem at all. You have on object which mandates
N fields passed into the constructor where
N is some number greater than the threshold for which you comfortable working with in a single routine.
Honestly, I get it. The mental burden placed upon a developer to understand a block of code with 500 variables is high and should be looked at with suspicion in regard to refactoring towards greater insight. But this refactoring must involve actual refactoring (i.e. solving the problem), not just moving/partitioning the problem around. Doing so often has a way of creating a higher mental burden or introducing more problems.
For example, your proposed solution creates a whole new problem where you need a new method of hydrating your domain object in a way that doesn't trigger any events -- as well as adding a user-defined external dependency to your domain (eek!).
All that said, will creating a factory method with the added dependency work? Yes. On the spectrum of design compromises, is it really so bad? No. Have I done the same thing? Absolutely!
*Don't let my purist vision get in the way of making progress. Everything is a trade-off :)
My answer above is mostly a tongue-in-cheek way of informing you (and whoever else might read this) about the trade-offs of your proposition - which I believe to be a minor compromise in the grand scheme of things.
More important than your specific problem/solution though, and where I fear I may have failed to be explicit enough, is about the dangers of using the way something "looks" as a means to appraise the quality of the design!
You see, the way something "looks" is a matter of perspective. Do you mean the class file looks cleaner? The package directory? Or maybe you mean the dependency graph looks cleaner? Often what "looks cleaner" from one point of view has the opposite effect on others! This is the problem with "design by aesthetics"; It generally opposes the low coupling/high cohesion ideal for which we should be striving.
Let's be honest, after you write the constructor how often will you need to "look" at it? I can say this, we know for sure that adding an additional dependency means at least one more vector of change that might prompt you to revisit this code where it would have otherwise been unnecessary.
Don't miss the forest for the trees! A system is bigger than any one file!