I would urge you to revisit your premise. If both endpoints will have an app on it, then your criteria for choice of algorithm are not valid: the app will be handling the encryption/decryption, not the user. Public-key crypto can potentially provide better security in this context; for instance, it may enable trust-on-first-use (SSH-like) key management. Also, I'd suggest that you start by first thinking about the threat model. The first question should not be, what crypto algorithm do I use? Your first question should be, What threats am I trying to defend against?
If you must use symmetric encryption for SMS texts, AES in CBC mode with ciphertext stealing is a plausible choice. Ciphertext stealing will avoid waste if the message to be encrypted isn't an even multiple of 16 bytes. You will still need an IV, which will take up some space. To save space, you could send a counter, and use the AES encryption of the counter as your IV.
If there's any way you can avoid transporting ciphertexts over SMS, avoid it. 160 characters is very limiting. Can you transport messages over the Internet?
If you can avoid tunneling over SMS, you might explore a model where the app has its own private/public key, and maintains a public key for each contact. When contacting someone new, the app sends its own public key, receives a public key from the other person, remembers that public key, and sends the message encrypted with that public key. This is of course vulnerable to man-in-the-middle attacks but may be easier to use.