As a developer who is now a manager, estimation is hard. As Scott said, you really mustn't beat yourself up about it; it's just hard. Frustratingly, the way to get better at it is through practice.
Personally (and your brain may well work differently), I find that the bigger something is the less accurate the estimate. Break everything down so that you aim for half-day chunks or smaller -- instead of "build login functionality", try "build login form + build lost password form + build login database" and so on. For some context, I estimated a Facebook application for a client today and the largest line-item in the spreadsheet we use was two days, when the project duration is two or three weeks build.
Remember that nothing ever goes smoothly, so take a guess as to how risky each task is and vary the quote accordingly. For the sake of argument, let's say that low-risk tasks should be inflated by 10%, medium risk tasks by 50% and high risk tasks by 150%. (I'm making these numbers up as I type, just pick something that feels right, then increase it some, to make sure you're not being too optimistic again.)
We use our bug tracking software (Jira, but any would probably do) to track work items too, and to log time against them. (This has the advantage of allowing project managers to see how you're doing against their expectations.) You don't necessarily need to do all of that, but it's a very good idea to keep track of your estimates, so you can go back and compare your performance against them later. That will allow you to gain an idea of the kinds of tasks that you underestimate and by how much.
The main thing you need to work out, I would guess, is in what way are you underestimating? Are you just generally being optimistic, are you underestimating the complexity of certain tasks or are you not taking account of the things that might get in the way (other work coming up, that meeting you need to allow a couple of hours for, that hangover you're gonna have after taking your partner out for Valentine's night, the time you're gonna have to spend googling how to get MVC to play ball with the data model you're passing in from this controller, whatever). Finally, what about amends time? In my day job, all our dev work goes through a QA team, who come back with bug reports. Those bugfixes are usually around another 15% of the build time, all told. So a project that's a week's build will probably have another day of bugfixing once it comes back from QA.
All that said, for the project you're on at the moment, stop where you are and review what's left to achieve. Divide that up into discrete tasks and re-estimate it. Then take a look at those risk factors and inflate your estimates accordingly. Then, when you're done summing that up, add some contingency (we apply 30% contingency to most projects, because shit just has a habit of coming up when you don't want it to).
You mention that you have some colleagues, but that they're not big with the up-front planning. Do you think they would be able to help you validate those estimates? Remember, when asking them, that they will work at a different velocity to you, so if you say that something's a 2-hour job and they think they could do it in an hour, what's important is how long it will take you to complete the task.
As I said at the start, though, don't beat yourself up over it. Development estimation is hard. And building something in a new context (a new framework or language or whatever) is doubly hard. Good luck with it. And don't worry: C#, .Net and MVC do get easier. And so does estimation.