I am not sure I agree with your observation that such a pattern is needed.
In my opinion the creation process of your object should be a part of one of your layers
(domain model,business layer or [put here some fancy layer name])
If you need too much lines of code to create an object then maybe you need to add a new object to your domain model.
Tomer, doesn't this depend on your choice of test isolation? In theory, unit tests should not depend on one another. They should set up a "known" state, execute the test and after compare the before and after states to ensure that the test succeeded. By this principle it is not acceptable to use any part of the domain being tested to perform the "state setup" and subsequent "state comparisons". As the system growns in size, you realize that there is a lot of duplication in these setup and before and after comparisons. Hence you refactor the setup and Assert logic into helper classes. These too can get "out of hand" and Roy is simply giving guidance as to possible containment patterns. The real trick is to build your test code with the same level of care that you put into the production code. This really starts to pay off as the number of tests grows.