Fundamentally underneath a shell is a TTY. Although it doesn't make up what you could call a CLUI. The terminal interface (text input and output) is implemented in the TTY while command processing is handled by the shell.
In DOS this is more like a batch command processor hints .bat(ch) files. While in Linux a shell is a mini programing language which also includes built in control structures.
That "login" script is actually the init program which is automatically loaded by the kernel after it loads its VFS (init can be incorporated into initram or wait until hard file systems are accessible) and it runs before ttys are loaded. In fact the init program must then setup the TTYs and then load services. sysvinit loads an interpreter shell and then uses init scripts while systemd uses INI like configuration files it calls units. A shell script is not actually needed at all during the boot process or login process but exec is.
The TTY is built into the kernel but can not interact with the user. Several commands such a login interact with the user over a TTY but are not technically command processors or shells. Other basic examples exist like the reset button on your router is technically a minimal way of interacting with the system. But any program attached to a TTY can take standard input and output from the TTY and process commands.
Ignoring the fact that you really need a shell to meaningfully interact with the system the most basic way you interact with the kernel is through system calls and the most basic one that passes messages is exec which is how command arguments are passed along.