To be honest, the best advice I can give is to find a new project; I am skeptical that this one can be rescued.
Step 0 is to manage communications. Sit down with the project sponsor (and whichever stakeholders are relevant) and tell them that this project is in serious trouble. Make sure that they understand that any estimate for schedule (and for cost/quality) are going to have a minimum error > 100%. Unless something dramatic happens you cannot make a credible prediction about the future of this project. Personally, I'd frame the conversation as a choice between two recommended choices of action - either cancel the project (recommended), or else choose to manage the project (because the current state is not project management; it is a recipe for disappointment).
Assuming that they agree to put the project under project management, the first step is to rewrite all the task descriptions to be crystal clear. The second step is to work with the SME's to develop credible estimates for each task.
Step 1 - develop estimates. Broker between the SME and the stakeholders/sponsor to achieve definitions of each task that are clear to both parties and are measurable. You cannot estimate what nobody understands. I don't have enough situation specific information but I suspect you're going to have to do this in an iterative fashion - select the earliest and/or most important milestones and clarify them first. See if you can get them clear enough to start production, and then create a process to clarify the remaining goals. This will be a huge task for you, but if you can succeed, you're going to build a lot of credibility for yourself and for the project.
Step 2 - work with the developers to develop a credible estimate for each task. "Credible estimate" means a best/worst/probable estimate with a confidence interval. (I believe that the mockup for the user interface can be accomplished in 2 weeks; I'm 90% confident that it will be complete in six weeks. If the existing code doesn't require extensive rework, we could complete this is 4 days. So the GANTT will show 12 days (PERT estimate (30+(4*10)+4)/6. Repeat for every task.
But don't get distracted by math and confidence intervals; the key to success is the communication with the developers. Developers have been trained to lie about estimates, because they've been held accountable for stupid estimates in the past. Your success depends on convincing them that (a) you will represent and defend them; they will not be penalized and (b) Estimates are estimates - you will communicate that these are estimates in a band - if a task is within the confidence interval, both planning and development were successful. Commit to work with them to continuously update the estimates and to communicate with management. My best approach in the past has been to guarantee that you will let makers work on maker time and you will bridge to manager time, and that you will defend them from managers. (yes, I'm being repetitive). In my experience, devs don't like estimation or tracking, they like creating; I offer to let them focus on the part of their job that they enjoy and I take over the part they don't enjoy (meetings, estimates, communication with non-developers, etc.)
You'll need to build in a management reserve - I'd suggest you begin by looking at critical chain method; that may help to build confidence with the SME/developers.
I've failed to be brief; the summary is that the project you've described is not being managed, and it will fail, damaging the reputation of all involved. If the participants want the project to succeed, they're going to have to back you in your efforts to manage the project, and the first steps are to clarify the tasks and estimate the tasks. Then pick up everything else from PMBOK.