The answer probably depends on how you are using your specifications, and whether the code is breaking a lot during the creation process.
Specifications can be used for almost anything you can think of. At a basic level specifications are merely controllable conditional statements encapsulated into objects. Wherever the code uses conditional logic one could probably refactor that logic into specifications, if the developer felt there was some justification.
There is nothing wrong with using specifications in the actual code, so long as it makes the code more usable, maintainable, or readable. There is also nothing wrong with creating specifications that are only used in tests. Specifications are simple objects, coupling code to specifications in one way or another doesn't seem to have much of a negative impact on maintenance or reusability due to the relative simplicity of most specifications.
If a specification for an aggregate
root product is being used for
validation, rather than for creation,
does it make sense to call it from
inside the factory?
Yes, but probably only if you are having trouble or a lack of confidence in the product of the factory.
Or is a unit test good enough?
Yeah calling a specification from a unit test can be good enough to prove the validity of a factory's product (at least in regard to what the specification covers). I don't often use specifications in my unit tests however, only when I'm having a tough time with something, or it's part of the logic that I'm testing.