I would say that the answer to both parts of your question is no: this calculator's commands aren't like assembly language, and programming this calculator is different from programming in assembly language.
The "language" this calculator is programmed in is fairly low level, but it still represents an abstraction on top of lower-level constructs that aren't visible to you as the programmer. I'm guessing a bit, but from your description, and from looking at the keyboard (and comparing it to similar-looking calculators from Hewlett Packard or Texas Instruments from the late 1970s and early 1980s) I'd say that each program "step" not only could be a simple operation like "add" or "swap X & Y" but also more complex operations like trigonometry, exponentiation, logarithms, etc. Each of these steps is probably implemented as a internal microcoded routine. That microcode probably is programmed in assembly language, but I don't think it's visible to ordinary calculator programming at the level you've described.
As others have described, assembly language usually is in very close (if not 1:1) correspondence with the facilities of the underlying machine. I'd say that assembly language programming includes the following characteristics that are probably not present in programming this calculator.
Operations include lower level level operations such as bitwise AND, OR, XOR, shifting; integer and (maybe) floating point arithmetic, on a variety of data sizes (e.g. single or double precision); load/store of a variety of sizes (byte, halfword, word, etc.).
Higher level operations (trig, logarithms) are usually subroutine calls, not instructions. There are some exceptions, such as the DEC VAX which had a polynomial-evaluation instruction. [Edit: OP pointed out that x87 also has trig functions.]
The addressing scheme of the machine is exposed. If the address space is segmented, you have to load a base address into a register and then address code or data relative to that register. Even with a flat address space, you're aware of addresses and address arithmetic. Usually assemblers will allow programmers to use labels to denote addresses. But if an address is in a different segment you may have to load a segment register before you can get to it.
Memory alignment is exposed. For example, on many machines a 4-byte word can only be loaded from or stored to addresses that are multiples of 4 bytes.
Data representation is exposed. Usually assemblers provide some way to specify numeric data in hex, octal, decimal, floating point, and occasionally character data.
Specialization of registers is exposed. Some architectures allow integer and address operations in some registers, but floating point only in others, or allow addressing only relative to certain registers. Sometimes there are specialized registers such as those with condition or status bits that cannot be used for addressing or arithmetic.
Subroutine calling conventions are exposed. Arguments and return values may be passed in registers, or pushed to and popped from a stack. (This stack is usually a region of memory addressed by a special stack pointer register, not a fixed set like X Y Z and T.)
You may need to be conscious of how to interact with the OS, or if there isn't one, how to deal with low-level hardware facilities. With an OS you have to load arguments into registers (or the stack) and trap into the kernel. Without an OS you probably have to deal with interrupts and timers.
My recollection of assembly programming is that it is very, very painful. I think that programming this calculator is easy and fun by comparison. (Sorry.)