Depends what kind of "fake and fudge".
As an example, I once worked on a platform that sat on a mobile phone and ran games written for the platform.
At the early stages of development, we "restricted" demos all the time. We'd get games from the game developer, and want to demo the newest, flashiest games if possible. But the newest flashiest games were the least well-tested on our platform, so maybe if you finished the level it crashed, or we had to sneakily rip out a bunch of textures to fit it all in memory, or it only worked if you rebooted the phone right before running it. So the demo was "supervised", meaning you don't let the customer just walk off with it. You either drive it yourself, or else you keep an eye on them, and you stop them going outside the safe zone of operation.
It's slightly dishonest, but I don't think it's unethical -- if the customer asked then you'd admit that there are still some undiagnosed bugs in the game/platform/both. But prior to first release, customers don't usually care about whether things work perfectly yet: they know that they don't, because if they did you'd have released already. Letting the demo crash gives a bad impression, because it implies you have undiscovered bugs you can't work around. Bugs you know about but haven't fixed yet aren't so much of a threat to the project, so don't let the customer see them unless they've signed something that gives them a right to view your blocking issues list.
As against that, compiling up a native-for-that-phone version of the game, showing it to the customer, and claiming it was running on our platform when it wasn't, would have been fraudulent. That's unethical and potentially illegal. So we didn't do that (and anyway, for at least one game the native Symbian versions for the demo handsets actually ran slower than on our platform. Heh.)
If all else fails, and you have to completely fake up a demo by hacking together a bunch of code yourself that looks like the real thing but doesn't actually work at all, tell the customer it's a user interface prototype, not a product build. Sometimes the reason they must see a demo is because they want to know how the product will handle, not because they want proof that the product works yet. Prototypes are usually a waste of time, and it's better to build the real product iteratively, but if they want to see a demo just so they can comment on the colour scheme, then show them the colour scheme on a bunch of faked-up, non-working windows.
If you're just being asked to produce the demo, not to show it to the customer, then personally I'd go on record that I thought it was costing time that should have been spent on the real product, but leave it to someone else to make the decision whether to lie to the customer. If the sales guys are determined to lie then you can't stop them just by refusing to produce the demo in the first place - they'll only tell a different lie. Usually you can't fix everyone else's ethics to match your own, all you can practically do is leave.
Being overworked is IMO a completely independent issue from faking demos. Ed Yourdon's "Death March" is a really interesting handbook for dealing with that situation, and the number 2 piece of advice (after "don't get into them unless you really want to") is knowing when and how to get out. The similarity with the fake demos is that sometimes you can't refuse just to do the bit you don't want to, you have to quite the job.