As far as I know, there's no reasonable way to put content databases on
different SQL Server boxes for the same farm. You can cluster your SQL
servers or use a failover DB server, but it's going to have the same
content. Your options for separation are (a) use separate farms, or (b)
keep the content outside the SharePoint farm and use BCS to bring it in
where required.

For the WFE question -- what do you gain by not running the apps on all
three? You're going to be using load balancing in that scenario so you
could easily tweak your setup so that a particular URL only gets routed to
one or two servers, but the IIS website will still exist everywhere (though
you can manually stop it on whichever servers you like).

1) If you have not configured Windows Network Load Balancing or have a
hardware load balancer in your environment then each web site will only be
served from one WFE anyway. So it is perfectly acceptable in a multiple WFE
environment to have different Web Apps served from different servers. In
fact this is the default setup for the Central Admin web application in a
multiple server environment. CA is only created and run on one server, no
matter how many WFEs you have. Load balancing normally has advantages, but
I have seen reasons why you would dedicate certain web apps to certain WFEs.

2) You can have as many SQL servers in a farm as you like. Its not
common, but there is no reason not to do it. In some cases it is a best
practice if you need to support higher service levels for certain site
collections.

I found out where you specify the SQL server - since it is per content DB, it
should be possible to put each content DB in a separate SQL server...I don't
know why someone would want to do that but...
I really appreciate the quick responses.

The only real reason I've seen it is to support specific service levels.
For example, you may have a service level that specifies a certain site
collection needs to be available 99.9% of the time or can't afford any data
loss. On the same farm you may have another more general site collection
that isn't supported so stringently. In that case it might make sense to
put the one on a SQL cluster while the other is on a regular non-clustered
SQL server.

It can be necessary to have additional SQL instances or servers to scale for a
very large farm. You reach a point where the SQL Server becomes a bottleneck for
performance. In that case, you can put (for example) service databases on a
separate server from content databases, or split content databases across
different servers. There is no dynamic load balancing, so you just have to
divide up the databases to try to spread the load as best you can.