Elements I've used to keep things flowing:
- Keep clear, concise and short-term objectives. ex: This week, we need to complete "this feature".
This needs to be a commitment from the whole team, not you tossing this over them. If they believe its possible to attain, they'll attain pride in achieving this, and shame in under-delivering. Try to keep the objectives realistic, but don't make them too easy or hard to achieve. After a while, the team will know almost exactly whether it can attain or not the objective it set for itself.
You will not need to do much motivation aside from recognizing their effort. They will reward themselves based on the work done.
The problem with not having punctual objectives is that the reward of 'completing the project' is so distant that interest will fade over time. This isn't the case with short-term objectives.
- Axe the obstacles: Your job as team lead is to remove any impediment. In this case, if you're also responsible for creative input, make sure you prioritize the core gameplay features, and are open to discuss the 'other stuff'. Its highly possible that some features won't be 'fun' to work on, despite them being critical to the end product. One way to axe the obstacle in this case is to push this to the very end. As with the following point, when developers see what they're building turns into an actual game, they'll be much more motivated to 'kill tasks' to get there.
But your role is also to bring the donuts, coffee, deal with their immediate constraints, and insure everything is smooth sailing. If there's a wiki to update, do it yourself. The less time they have to do 'something else than what they're good at', the happier they'll be.
One might argue that this makes it a boring job for you then, but you've chosen to be the team lead, plus you have the creative input, so someone's gotta pay for this ;)
- Develop an iterative product: A game with a fairly simple core gameplay will allow people on your team to quickly see 'results'. At that point, they'll want to iterate (beware of feature creep) on it to make it better, and because they have something playable in hand, the big reward of shipping a final product won't appear as far as it would otherwise.
For example, a platformer is good because you can quickly implement a few gameplay mechanics (jumping, running, etc.) and will iterate (add levels, add upgrades/power-ups, etc.)
- Listen. Remember the things they've brought up as potential risks. Ask them their opinion. Not just to motivate them (it will motivate them if you give them the credibility they are entitled to), but to not actually fail. If you've started this project knowing you needed other people, don't consider them machines that produce the stuff you need. More often than not, they will have creative or technical input that is critical to the success of your game. If there is not such a thing already in place, figure a way to have a common build review moment. If you are physically apart, you can do this through screensharing in Skype for example. Worst case, let everyone do their own build review, but make sure you have an open discussion about it (if morale is low however, people won't do the actual review on their own, and even if you insist on a group review, once again, if motivation is low, people will not cooperate).
Any update from the original post by the way?