No, a SSL server does not sign what it returns. The operations which use asymmetric keys and may qualify as signatures occur during the initial steps of the connection (the "handshake"), before any applicative data is sent, so these operations cannot logically bind anybody to the contents of such applicative data.
There is a possible source of confusion, which must be dispelled: during the course of the connection usage, all applicative data will be covered by a MAC. It so happens that some sloppy but widespread documentations incorrectly refer to MAC as "signatures". However, they are not signatures, not in the sense of "opposable proof". In a MAC, the secret value needed to generate the MAC is identical to the value needed to verify the MAC; this implies that whoever can verify the MAC also has, by this fact, the power to forge the MAC. Thus, a MAC cannot be a "signature" in the sense that you want.
Given a copy of the server's certificate, which is trivial to obtain (by definition, the server sends it to any connecting client), it is easy to build from scratch all TCP packets and the complete connection records corresponding to a fake SSL connection that cannot be distinguished from a genuine connection. This is easily seen, mathematically, by looking at how the protocol works: with a simple RSA-based key exchange (the most common case), the client generates a random key (the "pre-master secret") and encrypts it with the server's public key. Only the server can do the decryption -- but the client also has that pre-master secret: he generated it ! It is thus trivial for the client to emulate all computations that the server would perform in that situation.
If a complete and undistinguishable fake connection, with arbitrarily chosen contents, can be built from scratch without even involving the server at all, any recorded trace of a connection cannot serve as signature in any way. Such a trace does not even prove that the SSL server actually exists at all.