The signAndSend in the JS API is actually a process you can split into 2 parts: .signAsync(...) and .send(...), internally the JS API does exactly that when calling signAndSend(...).
However even when splitting it like this, the signatory is responsible for paying the fees. When you sign a transaction, the signature actually is over the transaction payload, which includes the sender address and sender nonce, so in transaction validation both of these are checked as the originator.
In the case of Polkadot, the chicken-and-egg situation where the user has no funds but has to perform a transaction was done as part of the claims process. Here a user would attest that he/she own an account, and have an action performed, without having any funds.
The details for attest you can find here
Basically the way that process works is to sign transaction with some account and then submit an unsigned transaction. A signed extension then validates this information. A similar approach could be followed: get one account to create a signature on some data, and then use another account to send the transaction.
As you rightly point out, for the default proxy pallet, you need to have some funds reserved to be able to create a proxy. (But like in your example, the sender will pay the fees). The difference is that the full transaction is signed by the sender and all fees paid there, the account being proxied never gets involved after the initial setup.
