Yes and yes and it already (almost) does.
Forward secrecy is defined with regards to the notion of "long-term secret". The idea is that any secret that is stored for a long time is potentially amenable to ulterior theft. Forward secrecy is obtained when stealing long-term secrets does not allow breaking past communications, and the easiest way to achieve such secrecy is to use ephemeral keys: if a key is not stored anywhere, then it cannot be stolen afterwards.
In older days, SSL/TLS implemented some "export" cipher suites that were meant to comply with the then-strict US export regulation on cryptographic software. When using an "RSA_EXPORT" cipher suite (like TLS_RSA_EXPORT_WITH_DES40_CBC_SHA), the server would have a long-term RSA private key; if that long-term RSA key was longer than 512-bits, then the server would generate a 512-bit ephemeral key pair, sending the public part as a
ServerKeyExchange message, signed with the long-term RSA Key. This mechanism was, ironically, meant to support the opposite of forward secrecy, in that the goal was to allow the encryption to be broken through even in cases where the long-term secret was not stolen. However, it demonstrates the mechanism just well: server sends an ephemeral public key for the key exchange, and that public key may be of type RSA.
Some noteworthy details:
Though the server sends a RSA public key in a
ServerKeyExchange message that it signs itself, and thus can potentially generate an ephemeral key pair, nothing forces the server not to reuse or even store that key pair. In fact, since generating a RSA key pair is a relatively expensive operation, most servers were reusing such key pairs for long period of times; possibly, the 512-bit key pair was stored in a file, or generated upon process startup and reused for weeks. This allows an attacker some time to break the key (512-bit RSA can be broken with relatively little computing power) and use that knowledge in some Man-in-the-Middle attack. This has been dubbed the FREAK attack.
Though the "ephemeral RSA" mechanism was defined, it was not updated to longer key lengths, because implementing it was felt to be too clunky and expensive. When SSL/TLS implementations use ephemeral keys, they do so with Diffie-Hellman (DHE cipher suites) or an elliptic-curve variant thereof (ECDHE cipher suites). Diffie-Hellman allows for very efficient generation of a new key pair, contrary to RSA. Moreover, ECDH tends to be a lot more efficient than RSA, both in terms of CPU (less work) and bandwidth (public elements are smaller).
Using ephemeral RSA key pairs would make sense in the very specific context of an very small, powerless client talking to a big server. On the client side, this would entail only public RSA operations (signature verification, asymmetric encryption) that can be made very fast by using a very small public exponent (e.g. $e = 3$). Clients that are so small that they cannot perform an ECDHE key exchange in reasonable time also have a hard time running a full-fledged SSL/TLS protocol, because of network issues (bandwidth, latency because of the two round-trips...) and lack of readily available implementations that comply to the server constraints of such platforms (code size, very little RAM...).