The problems raised here seem to be problems with the existing model of web-development-for-hire and consulting: this is a system that's focused on iterative design in a client-consultant model, not in prototyping as a product.
The key question to whether this can work is this – can we product-ize web application prototyping to make it less like contract hell and more like a turnkey product? I think it's possible.
There are two problems that were highlighted here. I think both of them are addressable, so I'll mention each in turn.
The first is the lack of a specification.
While in a PSD-to-HTML conversion, the screenshot is a spec by itself, in a PSD-to-rails conversion, screenshots aren't specs. There's a way around this; the practice of reducing ideas to specifications is the process we undertake as engineers, so it certainly can be done without any special skills, and shunting this work to the customer as a prerequisite before they can use the service doesn't seem to be a problem.
The second problem pointed out is treating this as contract/consulting work with extensive one-to-one communication rather than a quasi-automated service of compiling apps from a spec, and dealing with the agony that goes with it.
Contract work often ends in debacles (I've experienced it myself). The key to success here would be to _not_ implement this as one-on-one contract work. The goal would be to offer turnkey product prototyping as a product.
I believe that enough automatic barriers on what's uploaded can force a customer both to define specifications and prevent the endless back-and-forth that happens on mercenary work. I'll think about this a bit more and we'll see what can be put together.