A real example: My boss asked me how long it would take me to deploy the software on a new piece of hardware and run through the manual acceptance test procedure. I'd done the test procedure on other systems before, so I knew the whole thing took about 2 hours. I also know that deployment, installation, and configuration takes about 30 minutes. There are other factors, but let's just take these. I could very well say that it will take me 3 hours to do everything that was asked...assuming that the system was on the network. My assumption was that IT had done their configuration of the machine to put it on the network, and I could just log on and deploy the software. If they hadn't, my estimate would be blown already, since I couldn't do anything until that happened.
Assumptions aren't "evil things that like to stay hidden". They are things that you are counting on to have happened that are out of your control. You can present your estimate with these assumptions that these other things have happened, and outline what exactly you assumed would happen.
By enumerating and making your assumptions known, you didn't make an ass out of yourself. In fact, everyone's now on the same page. If you get into the situation and something didn't happen, you can point to the assumptions that you based your estimate on and then reestimate based on your newly found knowledge that the original assumptions were wrong.
You won't be able to account for everything. Some things will be overlooked. The only thing that you can do is keep track, learn from your mistakes, and get better next time. That's why you (especially at a project level) reestimate frequently - NASA's Software Engineering Laboratory estimates once at the start of the project...and then again 5 times throughout the project, revising based on clarifications, information learned, risk analysis, and assumptions made.