For many clients, describing what an application will do, or enumerating a set of requirements, is not enough for them to fully grasp how it will work. This leads to the infamous mid-project changes and scope creep. One way to mitigate this is to create a throwaway version that lets them see a "working" example of how the real application will operate.
It can often function as a proof-of-concept as well, but I think client communication is the more useful purpose of a prototype. In particular, you may want to do a prototype using a different technology -- Ruby/Rails, say, or pure Javascript -- than the final working application will use. If so, there's still proof-of-concept value in terms of the algorithms you're using, or the ways you may have to connect to other systems, but again, the actual code will all be thrown away.
So the part of your description I would disagree with is "add the rest" -- I'd throw the prototype out and start over.