The beauty of Config Migration is that it really didn't care what you were doing: Test to Test, Prod to Test, etc. It's just creating a standalone instance, does the DBUtil for you, does the base migrate for you, etc. It's also in the GUI which helps newer developers.
In trying Test System Creation, there's apparently a showstopper. I'm straight guessing here based on the error.
EDIT: Here's the real "problem" now that I've had a chance to dig deeper.
If you have any pilot/eval licenses in place that are near to or past expiration date, TSC throws a message that leads you to believe that Multi-User Server (or Single User Server) is pilot and expired. Which isn't true.
There's apparently an SCR about the message, but not about the root cause, which is what I believe I've just found.
When you log into Config you get a warning about any pilot licensing that's due to expire. My theory - and it's only a theory based on what I'm seeing - is that TSC is encountering the equivalent of this pilot expiring/expired message and just bombing without due diligence: "oh, they're secondary licenses, I don't care, I'll just keep going" or even better, "oh, it's a Development environment, I don't care, I'll just keep going". I also don't find a way to proceed past the error; some switch that says -IGNOREPILOTWARNING or something, so you're not completely stopped.
More info: it may only affect test environments created through Config Migration and activated with a certificate, vs. a callback code. More investigation happening.
Config Migration, of course, didn't care. It happily created the database without being completely blocked, and even when there was an issue, you always had a way to fix it.
