Personally I think it would be crazy not to start with putting fake screenshots in front of users to get feedback before you invest development time and energy on what is likely to be the wrong thing. Iterations with a graphic designer are a lot cheaper than iterations with a development team, and are nearly as effective for identifying large usability issues.
The trouble with user feedback normally is that people can't get a sense for how it would work unless they can see it. Sure you can make them put it in writing, but if they haven't seen it they almost surely asked for the wrong thing. So you really need to get them something they can see before you get useful feedback. And you want to do that in the fastest way possible. (Albeit while generally making it clear that actually getting it will take time.)
Back in the 90s, when I worked in consulting, it was business as usual to have a meeting with the client and the next day be back with a mock-up of the application features or interface discussed the day previously. It might have been VB, just GUI with nothing behind it, but clickable. It might be a few flat HTML pages (that would be connected to a database if it were real). There would be no graphics or "polish", it might be literally just black and white and maybe a little line drawing or clip art. The user could play with it and say yes, build this for real and make it look pretty, or let's change this bit, and we would and be back the next day. We even had a fancy name for it, which I can't remember offhand, like Rapid Prototyping Workshop or something. Competitors of ours did this by sending it offshore and having it worked on overnight but we never did 'cos it was as much work specifying it in enough detail to do that that we might as well just hack it up on laptops ourselves in a hotel room.
Anyway, not only is this approach nothing new, but at no point was it ever claimed that anything existed that didn't, and clients were very happy with this approach (esp. if they'd been used to "business analysts" drawing "data flow diagrams" on paper then coming back a year later with a steaming pile of crap that did nothing anyone actually wanted).
It makes sense to show potential customers pre-development screenshot mockups but I find it mildly sleazy to deliberately lead them to believe that these are screenshots of an actual working system.
A few years ago I found myself working 70+ hour weeks for nearly 2 months because the client whose project I was put on had sold their software product to a large telecommunications company before it was even specced out, let alone developed.
I don't mind faking screenshots to drum up business and test how viable an idea is, but if you accept money for software that doesn't exist, and then demand a ridiculous turn over time from your development team (whether in-house or outsourced), then you're scum.
I must say that while I agree, I think that in this situation you (or your company) greatly profited from the bad planning of your client.
Put another way: your client also paid a lot of money for their jumping-the-gun, but I'm sure this was calculated into their sale price, and was probably not bad planning at all, from their perspective.
The trouble with user feedback normally is that people can't get a sense for how it would work unless they can see it. Sure you can make them put it in writing, but if they haven't seen it they almost surely asked for the wrong thing. So you really need to get them something they can see before you get useful feedback. And you want to do that in the fastest way possible. (Albeit while generally making it clear that actually getting it will take time.)