I agree with everything Todd said, and want to add a few points:
You note that
Because any progress on the burn down chart is not indicated until we close the issue.
This is by design. The idea behind Scrum is that if you have a Story that you've been working on for 3 days, and it isn't done yet, then that Story is 0% done. The reasoning behind this is that, given that a not-completed Story provides zero (or negative!) business value, by treating them as 0% done, you avoid the Team having many '90% done' Stories in play.
You also note:
We are [...] doing point-based estimations. [...] can't we do hour based estimations with GitHub?
Perhaps I'm misunderstanding something, but if your Teams are estimating in Story Points, then... why are you trying to get a tool to allow estimating in time? What is your reasoning behind wanting to do estimation in time? On the assumption that the answer is 'because we need to forecast when certain features will be complete', then what you can do is take the amount of points estimated and divide it by the average velocity (of the Team). Likewise, if it is for some other reason, first consider if you really need to be tracking time in the first place, or if you can solve your problem another way.