Sort of. You can’t create a transaction spending an output that doesn’t exist at all; your transaction needs some input. It’s more like if someone sent you a wire transfer that might take several days to finalize, and in that interval you could speculatively spend those funds. If the wire transfer finalizes, your speculative spends also go through; if the wire transfer fails, then so will your speculative spends.
In theory, txid non-malleability allows for arbitrarily large chains of speculative zero-conf transactions to be created and published to the mempool. In practice, no one actually wants to accept zero-conf funds, because they could be double-spent (the wire transfer failing in the above example).
What this is really useful for however is when you want to collaboratively prepare a transparent transaction with another party (such as opening an off-chain channel), and want to ensure that you don’t lose access to the funds you are providing if the other party starts misbehaving. The way you achieve that is by creating two transactions simultaneously:
- The first transaction spends the funds from you and the other party, putting them into a P2SH address (corresponding to a script that does something useful, and has some fund recovery pathway).
- The second transaction spends the funds in the P2SH address via the recovery pathway, and returns them back to you and the other party.
You prepare both transactions, and then both parties sign the second transaction (to ensure you can recover your funds) before signing the first transaction (that allows your funds to be spent). This only works if txids don’t depend on signatures (otherwise you would be forced to sign the first transaction before the second transaction). Furthermore, it requires that txids are non-malleable, because otherwise you could prepare both transactions as normal, and then the other party could malleate the first transaction to change its txid before getting it mined on-chain. You would be unable to use the second transaction to recover your funds because it would be referring to the old txid of the first transaction, which can now never exist on-chain because that would require double-spending the inputs.