It's true you can't make an iPhone app directly from the Air SDK, but Air, Mobile Safari and Android are all built on the WebKit browser. That means that there are only a small handful of very major differences between the platforms, so if you write your code to minimize the differences and isolate the differences in separate classes, it's actually pretty easy to keep your code base almost identical across systems.
For example, in Air and Android, you have the option of accessing the local SQLite database through either synchronous or asynchronous methods, with or without transactions. If you aren't used to asynchronous programming, you'll probably want to go with the simpler, more linear synchronous route; and maybe transactions will seem overkill to you. But because Webkit on the iPhone does not support synchronous database calls and everything is done through transactions, you'll be really stuck when it comes to porting your app to the iPhone. But if you write your own Database class so it is asynchronous and transaction based, all you'll have to do is write an interface or bridge to make your class work on all three platforms.
Air has a small mountain of features that you should probably stay away from if you want to port your apps quickly across all platforms. For example, you are allowed to write files to the user's local file system. Stuff like that is simply not allowed on iPhone, so don't expect it to port.
To get your code working on the iPhone and into the App store, there are several webkit wrapper frameworks. The two I know best are PhoneGap and Titanium. Titanium has the added benefit of publishing directly to both Android and iPhone, though I've never actually tried it myself. I do have lots of experience with PhoneGap, and while it is still pretty buggy, it does make it pretty simple to get your apps into the store.