If you already have the three points you mentioned above, you don't need a burndown chart to estimate the completion date of the project. When you divide total story points by the velocity, what you get back is a number of sprints, which are time-boxed (usually) to weeks which you can then layout over a calendar and get the completion date of the project. Drawing a burndown chart will just show an ideal line between your start of the project and the same completion date you computed. Not very useful.
A burndown chart is useful not to forecast the completion date, but to show if your actual progress is happening as the progress you forecasted. You have an ideal line on the burndown, and an actual line that shows you if you are behind (above) or ahead (below) of what you ideally forecasted. Seeing that allows you to take action and correct your trajectory if you still want to deliver on the desired date.
Of course, all of this is just a bunch of ideal things you think will happen. It's a forecast, not a prediction. A lot of things turn out differently once the project is underway.
A burndown doesn't show for example if the backlog changed; you just burn through story points. A burndown doesn't show if priorities changed, or if you work now on what you thought you will work on or on something else; it just shows how many story points you burned and how many are remaining. You also assume that things stay the same once you have drawn your ideal burndown line.
But of course, things change. If people focus on building the right product, then things will change after you have done your initial forecast. If you use the burndown chart badly, some might force the team to make efforts and follow the ideal burndown line and just burn through a bunch of stories or features that should be completed by the estimated date of completion. You now basically get Waterfall with a big upfront planning and the assumption that the forecasted things are correct and any deviation from it is bad, which in reality is the other way around.
If you want to find out more about forecasting deliveries in Agile, you can start with these posts: