Re: Interface Builder, I agree, but I don't think anything like that would work well for Android. It targets all kinds of devices and screen sizes; it really has to be flexible and that'd be harder to do with a WYSIWYG UI tool. That being said, someone made one for Android, but I still prefer coding it by hand: http://droiddraw.com/ (it ain't the prettiest thing but it seems to work; you can even load up your own layouts).
I don't question the rest, and I simply don't know enough about the iPhone APIs to compare it to Android, but I will say this: everything certainly works together in the Android APIs. I'm not 100% sure what the purpose of CoreData is - preferences? generic data storage? - but they are both part of Android as well.
Funny that you mentioned everything working together (albeit in a different context); that's the biggest difference I noticed between how iPhone apps work and how Android apps work. See Activities (Android) vs. Apps (iPhone), Content Providers, Intents -- just about everything about Android apps is designed around working together. For example, in every iPhone app I've used that has a browser in it, it's always essentially a WebKit view with some primitive controls, or it says "Halt app and switch to Safari?". In Android most apps open up the native Browser app's main activity, and hitting Back will close it and go right back to where you were. It's not really based on multitasking or switching apps, it just reuses the Browser's Activity to accomplish the same task. Applications are all on the same level, even built-in ones, and can all work together beautifully by simply calling Activities of other apps for performing specific tasks, or controlling them through Intents, etc. iPhone apps tend to be much more isolated.