The boot.img that is responsible for booting up Android, has their init scripts embedded in the RAM Disk of the actual boot.img which mounts the partitions into the respective /data, /cache, /system mount points respectively.
By altering the init scripts to hit on the SDCard, could lead to an unstable system, furthermore, reducing the life of the SDCard via wear and tear of the SDCard - why?
The kernel when booting, is loading from the / which is within the same partition as the boot partition - hence the need for the RAM Disk to be present along with it. It is that, which gets loaded into memory - a temporary file-system, in order for the init scripts to be read in and executed. Once the mount points are established, then the RAM Disk gets removed and thereby, the temporary file-system a lá RAM Disk, gets "flipped" over to the real partitions at a later stage during the bootstrap.
This is where the RAM Disk comes in - only temporarily, it is through that, the whole process of booting can happen.
The chicken and egg is this - the kernel prior to boot, has no idea what partitions are there!
Not alone that, by hard-coding the SDCard into the kernel's init parameter, which is a specific option that can be passed into the kernel upon boot in which it alters the kernel's processing of the environment.
The wear and tear of the SDCard would be significantly increased, not alone that, the entire Android ecosystem would drastically change, the API's have defined internal storage and external storage - so it could lead to confusion in where to store their own content providers for contacts etc, "Are we sitting on a external storage or internal storage?" from the perspective of Android itself, bear in mind, the content providers itself are housed in internal storage and from an overall picture, its one of de-facto standard convention for Android's file-systems involved.
So to sum up, I do not think that's possible, not ruling out its impossible either but if it can be done, chances are it will be tied intimately to the handset itself, give or take, what manufacturers put in there from a perspective of partition format types (yaffs, emmc, LinusStoreIII, and more importantly, the SDCard handling mechanism from the kernel/hardware viewpoint will be different - am talking about different IO addresses here) and not alone that, differing sizes of the partitions also, this would make the whole concept of Android - not exactly portable either due to non-standard scripts found within the RAM Disk itself.
