[Galaxy S I9000 General] RyanZA:
That won't work.

All of this information is available already, and there are a ton of posts and methods for different lagfixes that use it, but you aren't really interested in reading it seems, so I'll try to summarize how this stuff all ties together. It should help out most people reading this thread too. :)

When Android boots up, the first thing it will call is init which is inside the ramdisk. init uses the configuration file 'init.rc' which follows the 'Android Init Language', which is a fairly simple parser that uses something called 'services' to start up background tasks such as Zygote (android system). /data is mounted inside init.rc. Since init.rc and init are both inside the zImage, they are impossible to change without compiling (or modifying) an existing kernel.

One of the services which is started by init.rc is the '/system/bin/playlogos1' which shows the boot logo on the screen. It is possible to hijack this binary by replacing it with a script and then calling the replaced binary when the script is finished. (This same method does not require playlogos1, and can be used with any of the services that have the property 'oneshot').

So now for the actual lagfix methods (in a very general sense) that exist:

Voodoo is a custom kernel that replaces the init binary with a script that transforms /data over to EXT4, and modifies init.rc to use an EXT4 mount.

OCLF (and similar, there are a few) uses the playlogos1 trick to use a loopback mount (and bind mounts for accurate space reporting) to mount an EXT2 partition on top of /data. Works surprisingly well. This is currently the most widely used type of lagfix, because of it's ease of installation and use.

z4ziggy's z4mod (which should be released soon, it seems) is similar to Voodoo in that it requires a changed kernel, but it does it by extracting the ramdisk out of the kernel, and uses at-boot patching of init.rc to mount the correct filesystem to all mmc and stl partitions. This is, in my opinion, the best lagfix method.

There is also the option of using an external SD card specially formatted with EXT2/3/4, and using symlinks or bind mounts to overwrite /data on the internal memory. This is known as the mimocan method. Similar to this is using /dbdata as RFS instead of EXT but has serious space issues.

A final option, and fairly similar to what you are proposing is my 'NativeEXT' method which overrides all of the services in init.rc with scripts that sleep until a second script completes, and then continue. This allows /data to be unmounted after bootup has been completed, and the mmc can then have it's MBR changed to allow for /sdcard to be resized and an EXT2/3/4 partition created in the empty space, and then mounted onto /data (with care taken to leave the already created sockets files in RFS in their correct position).

As you can see, the 'NativeEXT' method which you are proposing is actually the most difficult method! It does work (I used it on my phone for some time to great effect), but the sheer complexity of the method makes it a bit unpractical. :)

At any rate, z4mod (or Voodoo) are the best lagfixes, and the EXT2 loopback method has thus far been the most popular. Work is being done on Voodoo to make it easier to use, and (prediction) z4mod should end up being the 'winner' of the lagfix race in the long run. :)