No.
Well, normally F.D.E. has to be in hardware (not Linux) else where does the kernel come from. Assuming you've resolved that (perhaps related to your suggestion of a less typical boot process)...
It is not possible to mount the root fs from a block device decrypted by a command-line option. Nor is it possible to mount ecryptfs as the root: you must have setup the backing filesystem for the ecryptfs before you can mount ecryptfs...
(Technically there is a hacky option rootdelay=. But there isn't a boot option to mount two rootfs on top of each other, and there isn't a boot option to decrypt a block device with any scheme).
Typically /proc/cmdline can be read by any userspace process, so Linux does not encourage putting put secret keys in it. Reconciling such an idea against the security needs implied by F.D.E. is challenging, but perhaps there is some contrived circumstance...
It almost sounds likeas if you want to pass the kernel a blob of userspace code, which can construct the storage stack in any way you choose. Even ways which kernel developers would not approve :-). You could pass the blob at boot time. Or you could have an option to build it in to the kernel. We could call it an initial ramfs or initramfs for short. Good news! Someone already implemented this kernel feature for you.
The question doesn't say why this 9-letter word must not be spoken. Since you're doing a custom compile, you can always patch in whatever name you like :-P.
(This is the more generic option. Technically for your case, you might use an unencrypted partition to hold the same code, but it's generally less convenient).
It does not have to be as large as a distribution initramfs. For example a quick search found this as a plausible starting point:
https://gist.github.com/packz/4077532
and you can build a custom busybox, which only enables the modules the initramfs needs. Depends how well the static linking works, but I'd really hope that initramfs would be smaller than a kernel.