Generating a pseudo-random stream from a key, and XORing that stream with the data to encrypt, is done on a regular basis. That's how most stream ciphers work, e.g. the well-known RC4, and also applies to block ciphers in counter mode. This is not "One-Time Pad", by definition, since OTP requires the key stream to be truly random (that's the condition from which the OTP unbreakability comes). Such stream ciphers still share with OTP the absolute necessity of never reusing a given keystream for two distinct messages, so the encapsulating protocol must take care to renew keys when needed. In SSL/TLS, a new session key is generated for each connection, so when a stream cipher is used (RC4), things are safe.
There are quite a few stream ciphers which have been seriously looked at by cryptographers, who found nothing bad to say about them; see the eSTREAM portfolio for a selection of those.
Chaos, fractals and so on, are not the right tool for cryptography. A chaotic system is just a producer of values which "jump around" in a seemingly random fashion. Statistical analysis tools could be defeated by a chaotic system. But statistical analysis tools are dumb: they are designed to analyze physical phenomena. For cryptography, we want to defeat an intelligent attacker who has a copy of the same software than the one you use, save for the keys themselves. For instance, a Linear Feedback Shift Register has very good statistical properties and produces bits which statistical tools will declare "plausibly random". But for a $n$-bit LFSR, it suffices to observe the first $n$ bits of output to learn the complete internal state, and predict all subsequent output with 100% accuracy (even if the LFSR structure -- the corresponding polynomial -- is unknown, $2n$ output bits are sufficient for that, with Berlekamp-Massey algorithm).
In short words, if you use fractals or a chaotic system in a homemade loop, you will make a cryptosystem apt to defeat a chimpanzee. We cryptographers usually aim a bit higher than that.
Also, secrecy of "the code" (i.e. software) is usually not assumed, because it is very hard to achieve. Software exists in some permanent storage, on a computer hard disk; there's source code somewhere; it is bulky. Keeping code confidential is hard, and even harder is knowing how much confidential it is. This is why cryptographers talk about keys: they split the "code" (e.g. a pseudo-random stream generator) into an algorithm, which is public and becomes software, and a key, which is a small sized parameter which concentrates confidentiality. A typical key is a sequence of, say, 128 bits, small enough to be handled and protected properly (it can even be remembered by a human, and typed back when it is needed -- thus, no need for storage on a hard disk).