There is no real problem with applying "false start" to PSK cipher suites. The "false start" thing is about beginning to use the negotiated key to encrypt data before having confirmation (with the Finished message) that the peer really agreed on the same key. In that sense, the peer authentication is still implicit at that point. This is not a worry for "normal" cipher suites. (Note: it might be a problem with SRP, though.)
If you want to target low-power embedded systems, you might want to use the ChaCha20+Poly1305 cipher suites (RFC 7905) which are a lot lighter than AES (especially AES/CCM, which invokes the AES encryption routine twice for each block). If you still stick to AES, and AES/GCM can also be lighter.
Also, while PSK is light (no asymmetric crypto), it has its own issues, namely the need for a shared secret, which is not the easiest thing to deploy; you might want to consider using a non-PSK system with a certificate. If the constrained system is the client, then RSA key exchange involves only public key encryption on the client, and that's lightweight, because RSA public key operations use the public exponent, which is short. Alternatively, some elliptic curves can be light enough for an embedded CPU.
Shameless plug: consider BearSSL. It's not yet ready for production use (in that I have still not made extensive automated verifications against a fuzzing SSL/TLS implementation) but can give a taste of what is doable. On a 48 MHz Cortex-M0+, my C code can do an EC point multiplication in about half a second (half that value if using Curve25519).
