Well I certainly wouldn't go making a bunch of changes unless you know
exactly what the issue is. Determining if the SAN is the bottleneck and the
true source of the problem is not that difficult these days. And if you can
determine that it is you need to also determine why it is. Is it due to the
fact you are reading or writing too much data or is it simply misconfigured
for the load?  I have seen many systems try to upgrade their storage only to
find out that some tuning and optimization in the code or schema saves a ton
of I/O and costs a lot less money. Is the SAN configuration not appropriate
for the load?  Most SAN's are not properly configured for a high end SQL
Server load but that doesn't mean you can't fix that. Both of these are
certainly easier to fix than splitting the db across several servers.  It
really sounds to me like the database code or schema is simply not optimized
for such a large db and that needs to be addressed first.

I agree with Andrew that having you data on A Big SAN Disk is not a guarantee
that performance will be anything near optimal.

I've witnessed cases where moving databases to a single 7200rpm sata disk
actually improved performance (I'm not exagerating here :)

So, if you haven't already, try first to figure out how exactly the SAN is
configured, and if improvements can be made there. I realize this will
probably mean stepping on some toes :)

If nothing can be gained, the data dependant routing solution you proposed
is probably the sanest option, provided you have access to the source code of
the application.

More options are (high level white paper) discussed here:
http://msdn.microsoft.com/en-us/library/aa479364.aspx

Good luck,
Rob