You need to sign your messages and then encrypt them (sign-then-encrypt). The signature generation is performed using the private key from the publisher (sender) and the encryption is performed using the public key from the subscriber (receiver). The decryption is performed using the private key of the receiver and the signature verification is performed by the public key of the sender. The private keys remain private, the public keys need to be trusted.
only publisher can create messages
Anybody can create messages, they are just bytes after all. Only the publisher should be able to create messages accepted by the subscriber.
publisher & subscriber can both read messages and authenticate the publisher
Encrypt not just for the subscriber but also for the publisher and you should be fine.
offline message transfer
Sure thing, but note that you may still have all the problems of a transport protocol. For instance, you could be vulnerable to padding oracle attacks if you encrypt using CBC mode.
messages can't be read by non-participants
Only the subscribers (receivers) and publisher would have the corresponding private keys, so yeah.
subscribers can be mobile platforms (Android, iPhone), i.e. less powerful processors
Neither of the schemes here would be troublesome for relatively low powered devices (if you can call the latest sets of smart phones "low powered" with 64 bit operations, hardware crypto accellerators and over 2 GHz clock speeds for the top and midrange models).
messages lifetime target is 15 years
15 years is a long, long time in crypto. But if you use 512 / 512 bit curves and 256 bit symmetric cryptography (256 bit AES, for instance) then your message should be secure for a long time, unless crypto-analysis using quantum computing takes off on a large scale.
messages are small, a few dozen bytes
An ECDSA signature at 512 bits is already 128 bytes minimum, and an ephemeral public key (needed for ECIES) would take around 64 bytes. A few dozen bytes seems a very small amount of available message space.
I know that RSA can do this by encrypting a message specific key using a private key and decrypting using the public key (waving hands over some details here)
No, it cannot. The public key should be considered public.