Implementing your own SSL is not a small endeavour. It takes some effort to make it run at all; it takes a lot of effort to do it securely. The cryptography in SSL is subtle, and especially the implementation of the symmetric encryption (with block ciphers) is known to have some vulnerabilities if the decryption and MAC verification are not done with the utmost care (fixed-timing comparison functions and so on).
I have once written an SSL library in pure C, for an embedded system (ARM7TDMI). It supported a few cipher suites (with 3DES and AES encryption). It included a primitive X.509 path validation system (a streamable ASN.1 decoder). Complete code footprint, once compiled, was about 20 kB; the X.509 support accounted for 6 kB, and 5 kB for the AES alone (because of its precomputed internal tables). More importantly, the library performed no dynamic memory allocation by itself; it could run with a single, caller-provided 18 kB buffer.
If you really need to fit in the smallest code size ever, you should implement a single cipher suite using RC4. RC4 has known biases so, cryptographically speaking, it sucks. However, it requires no padding, which avoids a lot of the vulnerabilities implied with the handling of the padding upon decryption, so using RC4 in that case is probably not a bad idea.
You cannot avoid any form of key exchange. Otherwise there would be no point in using SSL. A "null HTTPS session" exists: it is called "plain HTTP" with no SSL at all. RSA-based key exchange is easiest for the client, since it entails only public-key operations, i.e. exponentiation with a very small exponent. You will also need it for validating the server's certificate (RSA signature verification). Some handmade "big integer" code with the few needed operations can be built with few lines of code -- but of course, you have to understand what you are doing.
Read this answer for a description of the SSL/TLS protocol. Also, get the Handbook of Applied Cryptography (free download !), especially chapter 14, that deals with (notably) big-integer arithmetic.
And get your code reviewed. Don't imagine that you can write code with no vulnerability; be ready to do the job again. A software project should be written three times: once to understand the problem, once to understand the solution, and once to do it correctly. Since vulnerabilities don't show up during functional testing, the only way to detect them is to submit your code to several (many) other people and let them look for issues.
