The power of Emacs is being command driven. The command for moving to previous line is:
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.
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.
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'...
I guess learning emacs requires some will to learn the environment and this implies reading text.
As for cheat-sheets there must be hundreds. If all you want is basic editing, jus anyone including save, open, quit and search must be sufficient.
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.
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.
 Ableson and Sussman rock.
I guess that learning emacs requires a will to spend time at the loo reading about it... Otherwise its pro-oriented syntax gets in the way at all times.
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.
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 am assuming that this is not just a feature of the Emacs configuration I downloaded as part of LispCabinet. http://lispcabinet.sourceforge.net/
Emacs' default bindings are also widely used but the chords are indeed horrendous.
† 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 general argument form of:
<there are lots of default keybindings -> learning default keybindings>
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.
That's very insightful. Thanks!
For example, this chapter:
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.
I wouldn't say never learn two things at once, but I'd be aware of the extra mental load you're creating for yourself. It definitely makes things more challenging.