What you are showing above is for keeping track/getting the info that is populated with a request to the XMPP server for it's roster (be it an autoFetch or a manual fetch using the XMPPRoster 'fetchRoster' method (assuming you have set the CoreData way of storing your roster data, not memory).
Once the response to the roster fetch is returned (iq result), the delegates within the XMPPRoster instance will capture and put in place with the given storage option. If the server you are using conforms to the XMPP rfc, then this should happen pretty automatically on the return.
For example - in XMPPRoster.didReceiveIQ() - you can see the call to '[xmppStorage handleRosterItem:item xmppStream:xmppStream]'. This is where the processed
You can extend the storage here (XMPPRosterCoreDataStorage and XMPPUserCoreDataStorage for example) and set in place to add additional information to the entity. For example here - XMPPUserCoreDataStorage has an over-ride '(void)didUpdateWithItem:(NSXMLElement *)item' that you can define attributes in to point to another entity. Here you would copy the existing data model and add your own attributes to it - using the over-ride above to enter them.
As for the messages, depends on if a MUC or a 1:1 - but they use different managed objects as well. XEP-0045 is what is storing the MUC messages that you can try to attach to for the users last message in there - as well as XMPPMessageArchiving for the 1:1 storage, but you would still need support from the server on this if you need to persist the capturing of another users last message - unless you are only talking about per session (which you could then store locally for display).