Your sprints are too large or too complex. Your sprints are failing a key test, putting a lot of work in jeopardy. I believe that a risk (user's not liking an implementation) is not being managed fully or properly, causing extensive rework. Your team's project management style is at fault and you need to plan your sprints accordingly.
Paper or screen mockups, accompanied by lots of handwaving, are much less expensive than code to produce (I'm assuming: you might instead have a killer UI mocking framework). A walkthrough or role playing with appropriate test subjects takes dramatically less effort than building and making a system ready for deployment. Since you already know that user acceptance is high-risk, and that you likely won't get it right the first time, you can plan for multiple iterations within the current sprint in order to get the feature set right.
Since a sprint should not have deliverable elements that depend on elements from earlier in the sprint, you should not plan to deliver the UI/feature elements that you decide on during the current sprint. Instead, the results of the testing inform the planning and development of the following sprint.
In my experience, it is not unreasonable for a sprint to include, let's say, a) code and finishing for hard-and-fast features, b) tech spikes for sprints indefinitely in the future, and c) UI & feature tests for sprints in the near future. This allows you to manage the high risk stuff while continuing to deliver solid, acceptable code with all the proper documentation, etc, that accompanies a product release.
In my last project, we had a sprint constructed with a mix of a) a one-paragraph description of a feature or UI element for review by the user group, b) a screen-shot walkthrough and hand-waving session, c) a prototype ready for play-testing of a feature from a previous sprint, and d) a ready-for-final-acceptance testing feature that was first presented two sprints ago.