The basic idea is for the students to build a Model for an application that might in some larger scenario be expanded to a complete Model-View Controller application.
The suggested application is a Dungeon Game. There are three basic kinds of objects: Characters, Places, Things. The Characters can move through the Places and can acquire Things and leave them behind. They do interesting things in the places: fight Monsters (a kind of Character), etc. The places are connected in some sort of, possibly dynamic, graph (map). The Things have capabilities to enhance the Characters and they can be carried from Place to Place.
However, to be successful at this you need some sort of development process. I suggest an Agile process in which you serve as Customer (Product Owner) and give them little bits of a specification at a time so that they work in small chunks (Stories) to extend a growing base.
It is a minefield to let them both specify and build the thing. On the other hand, it is nearly impossible to give them a complete spec up front. Much better to make it an agile project with someone (you) as Customer, feeding in Stories as you go. On Monday you give the students a few stories to build. On Friday you measure progress and prepare for the following week. Iterations are one week and it is fine if the stories don't all get built successfully. The learning is more important than the code.
Your stories talk about behavior. Say you describe a new kind of Character and what it's goals are, or a new kind of Thing. Students create the classes for these, but you need some sort of overriding set of Interfaces for the three basic types. Perhaps a Character can moveTo(aPlace), and can obtain a list of things in that place.
If you want them to have a chance to actually specify the world a bit you could have a discussion (open ended) on Friday in which they throw out ideas for things that you might add to the spec on Monday.
The advantage of an agile approach is that the students can be a success even if very little actually gets built. They will work on small pieces (set of stories) and have frequent successes. Otherwise they are too likely to take on big chunks and fail at those leaving chaos behind.
But you will also need to be careful that they don't take over and decide themselves WHAT to build. That is the customer's job, not the developer's. Students often have too little knowledge of the difference as most student work is underspecified so they have to fill in the blanks and get used to doing that.
You can also get them used to the small scale practices of Agile development here, such as Pairing, Test First, Stand Up Meetings and a few others along with Story-Driven-Development driven by a Customer.
If they don't do all of their work in a lab, however, enforcing the pairing rule will be harder (No code written by individuals can be committed to the base). Projects can fail when "prima donnas" build something that is inconsistent with everyone else's code/ideas.
They will likely resist the testing rule (No code written unless you have a failing test for the story first) at first. When they come to you with any question, ask to see the test or ask them to write one.
Two more ideas about organization.
Your students should switch partners while pairing quite frequently. As students this helps them learn to work with a variety of people. As professionals it helps them learn the code base as they only work on a part of it themselves but a new partner has seen other parts. The driver-navigator idea is also good here as the navigator has some perspective on the whole thing that the driver does not.
Also, since a Story isn't a complete specification for even a part of the app, a pair with a new story needs to consult you for more information so that they are building your idea, not making things up as the go along. Likewise, when they finish they need to get your sign-off on the work. This is just standard agile practice, but in a classroom it gives them access to your expertise as well.
This idea comes from Ward Cunningham in a private conversation.