First, read this advice by Jonathan Shewchuk, a computer scientist at Berkeley. While I do not 100% agree with everything there, I think it's at least 90% right, and well worth considering. Here a a few points I'd like to add:
Re: practicing. I say this first because it is hard to emphasize too much. You need to practice your talk. Multiple times. Out loud. Running through it in your head is good as a first step, but does not count as a practice run-through. The first time you practice the talk it will probably take 50-100% longer than the length of talk you are aiming for. Don't be concerned -- this is why you practice. The more times you run through the talk, the more familiar you will be with the organization of your talk, and you will not have to think so hard about how to express each concept, formulate transitions, and emphasize the main points. You will work out how to say what you need to in a more efficient way, without so many disfluencies (um's, uh's, and restarts). Take note of any particular places in the talk where you continue to stumble, and run through those sections by themselves a few extra times (maybe after sitting down to think more carefully about exactly what you need to say). Make sure especially that your introductory and concluding remarks are fully planned out and smoothly delivered -- these are the parts of your talk that will make the most impression on your audience.
After you have done all the steps above, you should try to find a friendly audience to give a practice talk for (e.g., members of your lab group or colleagues in your department). Besides possibly getting some useful feedback, it's good to know how feeling a little nervous might affect your talk. Personally I know that I tend to speak faster, so a 20-minute talk could become 19 or even 18 minutes. I therefore try to remind myself to speak slowly and calmly, but I also know that if my talk ran a little over time when I practiced by myself, it will probably be just right. Although my pattern of speaking faster is fairly common, I also know of people who speak more slowly with an audience. By testing out your talk ahead of time, you will be able to anticipate any potential problems.
Finally, if you have access to a video camera, it can be invaluable to watch yourself present, to discover any distracting mannerisms or other problems. However I wouldn't necessarily recommend doing this until you have a couple of talks under your belt already -- it can be rather painful to watch yourself, and early on building up confidence is the most important thing to do.
Re: minimizing words and maximizing pictures. The basic idea here is right on, although I'm not convinced it's always possible to do so as much as he suggests. Nevertheless, your aim should be to illustrate your ideas as much as possible using pictures, diagrams, figures, and running examples. (This is one reason I'm in favor of PowerPoint over LaTeX: LaTeX encourages lots of words rather than illustrations.) As Shewchuk notes, this requires more thought and more practice than just having bullet points.
Re: organization. Keep in mind that a good talk is not primarily about explaining what you did, it is about convincing the audience of something. Very generally (as noted by Shewchuk's page), you want to convince them to read your paper. But even if they don't, you still want to convince them of your main point, and to do that you'd better know what it is yourself. Figure it out, and work backwards from there to organize the talk. Consider how each section/slide contributes to your main point. If you don't know, should that section/slide really be included?
Re: onions. I think this metaphor may go a little too far, but the basic reasoning behind it is completely correct. The reasoning is this: People have limited memory and attention (especially after a long day at a conference) and they will space out during your talk. Your goal is to reduce the amount of spacing out (by keeping things clear and relevant), and to design your talk so that even if people space out or don't quite understand one part, it's easy for them to regain the thread and understand the whole. One way to think about this is through the onion metaphor (although I think the most important part of this is to give a high-level overview, as described above, followed by more details -- it's not clear that you need more than two layers). But equally important is to provide verbal cues (rarely, if ever, are bullets needed!) reminding people what you have already told them, what's coming up, and how everything fits together. A colleague refers to these as "signposts". Examples include: "OK, so that's the overview of my system, now I will talk about each of those parts in more detail", "I've now explained how we use X and Y to produce Z. Remember that what we are going to do with Z is A, so I'll now give you some more detail about that.", "One thing I haven't explained yet is X, let's just pretend we have a solution for that for the moment and I will get back to it later." In other words, think about your transitions, not just your slides.
Re: outlines. I've said it before and I will say it again: you should not need an outline for a 20 minute talk! The structure of your talk should be self explanatory, and going through an outline slide is boring and pointless. (Note that Shewchuk makes the same point; it's not just me.) On the other hand, it can be useful to have some kind of overview slide (which may or may not actually be titled 'Overview'). This is basically an abstract for your talk (and the first part of your onion-based organization). It tells people what you will be talking about, as well as your main conclusions. You should not be afraid to tell people your conclusions right up front, a talk is not a murder mystery. Once you have gone through the overview slide, you can then mention (briefly and verbally -- see discussion of transitions, above) how you will present the material you've just introduced.
To give you an example of some of the points above, take a look at this set of slides I made for a 10-minute talk presenting a 4-page paper at ACL 2010. Due to the short length of the talk and focused contribution, I didn't include any introduction/motivation slides (normally this is very important). I started right in with the overview, after which I said something like "in the rest of this talk, I will first explain the task and model very briefly and how the Gibbs sampler works, and then I'll give some more details about the Metropolis-Hastings sampler." So I've told people both what they can hope to learn from this talk and how it's organized. But I did not have a slide that said this:
Outline:
At least two other things are worth noting. First, I tried to explain things using figures and diagrams as much as possible, and labels/arrows pointing out critical parts of equations. Second, notice that I left out all details regarding the actual technical innovation of the paper, i.e., the grammar transform. I spent nearly the entire talk explaining the background and the problem that required this innovation to solve, and only gave a very high-level description of the actual solution. Remember, a talk is an advertisement -- my goal was to get people to understand why the work was interesting so they would come to the poster and/or read the paper, where they could get the real details. If this had been a longer talk, I would have gone into some more detail about the grammar transform. But it wasn't, so I didn't.
All this is not to suggest that this talk is perfect; you can probably think of some ways to improve it!
Further resources: please do not take any of the above as the one and only True Way; there are many ways to give a good talk. It can be useful to take a look at other people's advice as well, for example Matt Might's, which is also excellent and hits a few points that aren't emphasized here (as well as many that are).