How to assign an iRule to a profile?

Not sure I understand the question. An iRule can only be assigned to a virtual server (and an auth profile), but definitely not to a pool. You could create a single iRule and apply it to multiple virtual servers, and you can (with care) apply multiple iRules to a single virtual server.

I would also like to know why use an iRule to do this when you can enable the x-forwarded-for header int he HTTP profile.

The default behavior of the X-Forwarded-For header in the HTTP profile (at least in our version) includes the IP address of any server in the chain before it hits the web server. There are other discussions in the forum about this. Using an iRule, we limit the IP address in the X-Forwarded-For header to be just the IP address of the client making the request. It is possible that they have since provided an option in the profile to do this since I recall seeing some discussion about it.

Sorry I interchanged pool and virtual server. Right now we have this X-Forwarded-For iRule assigned to all external facing virtual servers. Since it is used everywhere, it would be nice if it could be assigned to our base HTTP profile. That said, I could see it being difficult to then order iRules among the total collection consisting of base HTTP Profile, child HTTP profiles, and those assigned to a virtual server. It's just that it's a bunch of work to assign a new iRule to all existing virtual servers.

The default behavior of the X-Forwarded-For header in the HTTP profile (at least in our version) includes the IP address of any server in the chain before it hits the web server

That's correct. If an upstream server also sends an XFF header, its value will get merged with the one that the HTTP profile creates. One option would be to simply disable XFF in the HTTP profile and replace the header with an iRule:

when HTTP_REQUEST {
    HTTP::header replace X-Forwarded-For [IP::client_addr]
}

That would effectively remove all other XFF headers form the stream. As for aggregating iRules, when multiple iRules are applied to a VIP, the contents and contexts of each iRule are merged together. If two iRules exists with the same HTTP_REQUEST event, for example, the compilation will contain a single HTTP_REQUEST event with the aggregate code from each individual iRule. You can in fact get yourself in trouble with this sort of thing, but given that you're simply replacing an ingress HTTP header with the above, I doubt you'd ever step on or conflict with any other iRule you added to the VIP.

Adding the above iRule to all of the VIPs on the box would be a pretty straight forward TMSH script.