This suffers from the issue that other introductions to Emacs* - including the official tutorial - suffer from: a focus on Emacs community mores. It skips over the idioms that make Emacs important and focuses on the predicate tribe-member?
The power of Emacs is being command driven. The command for moving to previous line is:
The mini-buffer is where one enters commands. The command for switching focus to the mini-buffer is:
Tell the new user what is really going on. To move to the previous line:
a) enter the command <M-x> to switch focus to the mini-buffer
b) enter the command <previous-line> to move the coursor
c) after entering the command, focus will return from the mini-buffer to the invoking buffer.
I don't have a hangup about calling <alt> "meta". New users already have somewhere to hang the mnemonic. On the other hand, until they have somewhere to hang <C-x p> it's not a mnemonic, it's just a weird way of doing stuff. In fact, giving the learner <previous-line> gives first, them somewhere to hang it.
What is typical of tutorials is that they jump past the well considered abstractions of the Emacs code, right into a set of customizations that made sense for the staff of MIT"s Artificial Intelligence Lab in 1979. These customizations were based on expertise with the software; the limitations of console interfaces with no drop-down menus, etc.; and most importantly many years to develop shortcuts on an ad hoc basis both for practical reasons and for the simple joy of productive laziness.
Perhaps <next-buffer> and <previous-buffer> are canonical illustrations of the way in which Emacs tutorials are more based on tribalism than pedagogy.
Could just as well be <C-b p> and <C-b n> or for that matter <M-b p> etc. or <M-x p> etc.
In the late 80's I went to vocational school to study architectural drafting, in no small part in order to get my hands on AutoCad. Part of that interest was AutoLisp. The best way to explain the idea behind AutoCad is that it was Emacs for vectors. And to some extent it still is, but there are increasing layers of abstraction. The important point is that it was and is command driven.
At the time I started with R10, there was no command aliasing except via Lisp expressions. So the alternatives were using graphic menus or typing full commands - e.g. "line" for the line command, "polyline" for the polyline command, "circle" for the circle command etc.
AutoCad output was controlled by pens and pens were mapped to the colors displayed by objects on the screen. The typical use was to map different object colors to different pen weights in the output device (in fact this was the only practical way to vary line thickness produced by the output device for a large number of objects).
Now, pen mappings pretty much needed to be standardized within an office because object colors were embedded in the drawing database, and despite their arbitrary nature, the number color mappings one needed to remember were small, they all displayed on screen like crap, and one only dealt with them from time to time.
As I switched between firms, each firm had their very own mapping of colors to pen weights. Each office's "standards-guru" would justify their selection of color->thickness as being obviously logical.
"Red is obviously the color for the widest pen because it is color index 1." 
"Blue is obviously the color for the widest pen because it is looks the darkest on screen."
"Yellow is obviously the color for the widest pen because it is looks the brightest on screen."
"Red is obviously the color for the narrowest pen because it is color index 1." [And so it goes]
The logic underlying Emacs shortcuts is identical. It doesn't make sense beyond, "This is what I like." All of it is subject to change - even M-x and C-x. That's the power, and that's what should be taught to new users.
What makes the application of the logic bad is that the number of "What I likes" and since the command language is completely customizable via elisp, there is no justification of standardization of shortcuts except within the Emacs tutorial infra-structure. I.e. it is simple just to copy the previous tutorial that was written for the AI Lab's undergraduates on work-study in the fall of 1982. It is somewhat analogous to the "standards gurus" who prohibited changing the command alias c->circle. Though they were more frequently ignored.
 Certain types of objects [traces, poly-lines] had a width property inherent in them and could be used reasonably for small data-sets or special cases.
 Colors were indexed from 0-255 with ACI being "byblock" so the logic was actually faulty.
* it also suffers from the fact that it is poor graphic design and poor typography, in my opinion. I'll leave aesthetic points about learning Emacs starting with leaving Windows for an OS with Vim as an exercise for others.
Challenge: embody your very interesting views about exposition and the need to explain 'what is going on' in a document that can be printed on one side of A4 and that allows someone to start editing text with emacs/mg.
I for one would be interested to see how your approach pans out as an accomplished design.
I have a mental image of a stack of buffers being shown as a sheaf of overlapping 'cards'...
The practical reason is that learning Emacs is currently a long term project, and the serious study won't begin until I get around to buying a hard copy manual. I know my learning style. It's depth first. I'm bookish.
So, I'm developing an outline - a sketch of what Emacs actually is. To me it looks like AutoCad of 1991 with a less powerful graphic interface - AutoCad had screen menus which were a context sensitive text based menu system. The difference between that and the <handfull> of Emacs extensions I have seen is that AutoCad screen menus were persistent and had a dedicated slice of the "window" (right or left side). They paged and predated pull downs in the interface.
Anyway, the picture that is coming into focus is that what tutorials are teaching is not the language of Emacs (commands and eLisp), but the language of Emacs users (shortcuts).
Beyond that, Emacs command language uses a verb-noun structure. This is both a natural product of its Lispy origin and lousy for users.
[The following examples are fictitious]
Lisp thinking tends toward being about processes not objects. A programmer will create a higher order procedure <make f> contracted
procedure -> procedure.
Call <make buffer> and get <make-buffer>. Call <next line> get <next-line>, call <previous line> get previous-line. It's all nice and tidy from a programmer perspective.
It sucks for the user. The user needs a buffer. Is it <create-buffer>, <new-buffer>, <add-buffer>, or <make-buffer>?
Auto completion doesn't help. The user cannot easily conjure the proper demon. This is where object oriented conventions rule the field. If the user knows the kind of spirit, they know the first half of the spell,  and auto-completion is much easier. <buffer.next> <buffer.new> are more user friendly.
Just because from the perspective of the code <next-buffer> may be more akin to <next-line> than it is to <previous-buffer>, it is not akin semantically. There may be a natural language which uses prefix notation, but even if there is, few computer users speak it natively. When Emacs was a tool for a small community familiar with Lisp, verb-noun probably was not an impediment to learning its intricacies. Now it may be something a full fledged tutorial needs to be cognizant of.
Finding a good set of key bindings is unfortunately not all that easy, and something I'd rather not have to do. What's frustrating is the lack of consistency within linux as to what are appropriate keybindings at the OS/Application level which results in a lot of binding conflicts (Unity, tmux, and most tiling window managers come to mind).
The default emacs keybindings strike me as particularly insane and not suitable for productivity or long term wrist health, but I use them because I don't want to go through every different mode as well as tmux, and my wm to figure out which bindings are going to clash.
I know that I should do it, but I'm lazy. If anybody has a really thought out set of bindings that are optimized for minimizing chords and sequence length as well as conflicts I would love to know about it.
What I'd really like is a scientific project to come up with a control scheme for the OS and emacs that maximizes keyboard efficiency.
The default bindings suck because (1) your control key is in the wrong place and (2) your meta key is in the wrong place. The first goes to the left of "A", the second underneath "/". Seriously: remap (getting meta right is hard, as keyboards aren't consistent about what they put there sadly) and try it again. When done right, your fingers stay closer to the home row than even vim (which requires frequent excursions to the shifted number row).
"Finding a good set of key bindings is unfortunately not all that easy, and something I'd rather not have to do."
There is nothing in the idea of teaching <next-line> as <M-x next-line> versus <C-x n> which requires finding a new set of key bindings. Emacs will even helpfully remind me every time I type <M-x next-line> that it is bound to <C-x n>. That's an absurdity within the standard approach to Emacs tutorials.
I agree that the specific key bindings are the least interesting thing
about Emacs.† This is the approach I tried to take in my tutorial:
http://david.rothlis.net/emacs/howtolearn.html -- namely, teaching you
how to find the commands you're looking for; finding the key binding
is trivial once you know the name of the command. If you have time to
cast your eye over the tutorial, I'd love to hear your feedback.
† However it doesn't really pay to customise the basic key bindings away
from the defaults too much, because all the major & minor modes have
key bindings carefully thought out to be consistent with the defaults.
The section of the tutorial on <vc-annotate> was along the lines of what I am getting at - i.e. the starting point for everything is <M-x command>. As critique, my opinion is that this should be the approach of introductory tutorials from the point immediately following "Installing Emacs."
The general argument form of:
<there are lots of default keybindings -> learning default keybindings>
is premature optimization for introductory Emacs tutorials - at least anecdotaly. The scattered evidence is that the default key bindings contribute to people abandoning the activity of learning Emacs. This is to say that it is reasonable to assume that default key-bindings are an impediment to Emacs adoption by new users and that thus the benefits of consistency between default bindings and calendar mode and IRC chat mode and email mode, etc. are never realized by most new users because they give up on the process and only a small percentage of those who adopt Emacs to some degree wind up living in it full time.
The argument form also ignores the idea that key-bindings can be aligned programmatically. Emacs is designed for programmers, after all.
In my opinion if a tutorial emphasizing CUA makes adoption rates higher, then the tutorial is more successful. The idea that CUA is not good Emacs is a social more, not an Emacs idiom. The emphasis on standardized keystrokes as the starting point in Emacs tutorials, logically parallels the idea that the first step to learning Emacs is to remap the keyboard to Dvorak for efficiency.
Someone wants to learn Emacs. They start with the standard Emacs key-mappings. Now they have two things to learn...
The second is the language of Emacs. The first is the gang-signs of the Emacs community.
The Emacs model has a command language and a means for making command language abstractions, elisp. The ability to make keybindings is feature of the process for making abstractions in the command language, individual keybindings themselves are values.
walks you through this example: What command is run when I press TAB?
How do I find out? How do I find its (elisp) source code? How do I find
the documentation for built-in elisp functions or macros or "special
forms"? All culminating in figuring out (from the elisp source code)
which variable you can set to customise your indentation level.
Point taken, thanks. I'm familiar with Eclipse for Android, but considering I'll likely be abandoning it for that purpose given the new platform, I'm hoping to pick up emacs not just for Clojure but for a general non-nano CLI text editing default.
I agree with this completely. I use emacs for clojure and I really like it, but learning a new language and a new editor at the same time is going to make things harder. There are clojure plugins for most popular editors at this point. Learn with an editor/IDE you understand and like and then switch editors later on if you want to.
For clojure, I'd actually recommend using light table. From my experience with the latest dev versions, the learning curve isn't hard at all and immediately having your code evaluated is pretty powerful and intuitive. [I started learning clojure recently as well]