While it is possible to do as you suggest, and many people do it, I question its wisdom. There are many aspects to consider.
The most important, however, is that if you are teaching CS then the likely most important idea (meta) is abstraction itself. CS is full of abstractions, with programming and programming languages being one of the key elements and so, is a good place to introduce it. In fact, having experience with both, it is abstraction that is fundamental to the overlap between mathematics and computer science. They differ in many ways, but share abstraction as a goal as well as a tool.
If you try to avoid an abstract view and try to make everything as concrete as possible then you are doing the students a disservice in the long term. If that concrete view were necessary then there would be no reason for high level languages.
As humans, we depend, fundamentally on abstraction in our human languages and in our interactions. It isn't a foreign concept as it might be to a chimpanzee. Computer languages exploit what the forebrain does best.
Note that your conception of a machine is wildly outdated. It is, in fact, just an abstraction. There was a time (more than half a century ago) when such machines more or less existed, but no more. Others here have commented on the differences. You aren't describing a machine, but an abstraction of a machine to which computation can be reduced. But a Turing machine is, itself, such an abstraction.
Almost all modern computer languages (some special purpose ones excepted) are Consistent and Turing Complete. The implication of this is that you don't need to go outside the language to explain computation. And, doing so can be a distraction from learning to use the paradigm represented by a language properly. You don't need to know how a "variable" in Lisp is represented to program effectively with them. You don't need to know the internal representation of lists (which might actually vary depending on the efforts an optimizing compiler might take.) to manipulate them. In fact, trying to reduce the Lisp notations to the actual actions of a physical machine is going to inhibit the learning of a novice.
Certainly, by the time a student has a rich and complete education, they need to explore many of the abstraction levels used in computing. They probably also need to know something about the mappings between the levels if they are to extend the field as researchers. But the first course is not the place to do that if it forces them to try to write every Java program as if it were a C program or even a minimal (abstract) assembly language program. The compiler course will explore those issues once they have a foundation.
So, as the answer of Ben I. suggests, you can start at pretty much any level of abstraction for the first course, say the OO level, which I tend to use. Stay with that level and show that any program can be written thinking about the abstractions and tools available at that level only. Use good metaphors for things, but treat them as metaphors. You don't need to leave that level to explain what a variable is, for example.
One of the reasons that people continue to suggest that this mapping must be taught to novices is that many teachers, having learned the field over a long period of time, actually grew up as the world of computing was changing, from simple machines and languages to richer and more useful ones. So, we learned low level stuff early on and that "helped" us when we moved to higher levels. It formed a base. And so, too many of us, in effect, teach with a historical view and ask our students to follow the same low to high path that we did. But, you don't need to recapitulate the history of computing to grok Python or Scheme. They are, remember, consistent and complete. In fact, if you try to do the entire history in the first course then the course will last for more than half a century and when you finish the course the students will be half a century behind the times. I've been doing this for half a century myself and I've learned a heckofa lot. But most of what I've learned is actually obsolete.
Pick an abstraction level (i.e. a paradigm). Pick a good language to represent that level. Teach that, so that students have the skills to understand computation at that level. Leave that level only with metaphor or with anecdotes, not to 'splain how it really works. Because it doesn't really work that way at all if you have ever peeked at an optimizing compiler.
The goal is insight.
There are two Lisp list functions that I find instructive for thinking about the functional paradigm. Neither requires any machine view. Both require some essential insight into functional programming. The two functions are to clone a list and to reverse a list, both in linear time. If you don't care about time, both are easy, but you need to think like a lisper to grok these. Try them.