An exercise in utility
Actually, there are two questions here. I'll answer the obvious one first. You can fairly easily solve the perverse incentive problem by having two due dates: one for the first 89% and a later one for the rest. If you have ideas about what they should do for the second part, don't reveal them until they turn in the first part. You needn't necessarily even mark the work after the first deadline, but you can, if desired. 

After the first deadline you have a version of the project. You can compare it with the second version to see what changes/enhancements have been made. In situations like this, I usually have students turn in work on paper and in the second version, mark changes (highlight markers) so that those changes are obvious. 

The second question is how much you want to encourage student "creativity" anyway. It isn't always good to let students loose without specific direction. There are two kinds of creativity: the what and the how. In the real world, it isn't normally the programmer who is responsible for the what. That is up to the Customer/Client/Boss/Organization. The creativity on what belongs to them. On the other hand, creativity (i.e. excellence) on the how is the key attribute of a good developer. For most assignments that is what you should be looking for. Do they understand the algorithms? Can they implement them efficiently? Is the code clear and maintainable? Is it tested and correct? 

So, I worry that if you just give an incomplete specification of the work and expect them to use their own creativity around what should be done, that they will get the wrong ideas about building things. As others have said in answer to other questions here, going outside your charter can be seen as a problem, not a blessing. See this, for example: https://cseducators.stackexchange.com/a/4539/1293

On the other hand, teaching creativity is also a goal of education and there should probably be one or more courses, or at least projects, where students do get to conceptualize, design, and build something interesting. But don't let them get confused. 



Caveat. Those who work at startups that define their own product have a different view. There, it is often the case that programmers participate in defining the product, but that isn't the common case.