In a game which is controlled by a gamepad, where control inputs directly change GUI focus from one GUI button to another, those GUI buttons should be activated when a controller button is pressed.
In a game which is controlled by a mouse (or if a gamepad is used to move a virtual mouse cursor around the screen), on-screen buttons should be activated when the mouse/controller button is released over the same button on which it was pressed. (If the press occurred over one GUI button, and the mouse was then moved, and released over a different GUI button, neither GUI button is activated)
The reason for this is that people's mouse control skills are highly variable, and often people have a little trouble positioning the cursor exactly where they want it, or even telling precisely which GUI button they're hovering over at the moment. The theory is that people can press and hold the mouse button to make the GUI button highlight, and if that GUI button wasn't the one that they intended to use, they can move their cursor away from it before releasing the mouse button in order to avoid pressing it.
But if your game is being controlled by a gamepad, then you absolutely want to take action when the gamepad button is pressed, not when it's released.
Edit, five years later:
In the time since this answer was posted, a new standard has begun to emerge for handling mouse-style cursors which are controlled by gamepads.
In the answer above, I suggested that these should be implemented to work exactly like cursors which are actually being controlled by mice; highlight on mouse-down, activate on mouse-up if the cursor is still over the same GUI element.
But now, gamepad-controlled cursors typically activate a GUI action after the gamepad button has been held down for a period of time (typically about one second). If you're going to follow this system, you'll need to have an on-screen indicator showing how long until activation will occur (often this is a little ring around the cursor itself, which fills up as you get closer to activating the hovered-over button), and you still need to highlight the element which will be activated, during the time that the button is being held down (and it might be a good idea to do that any time the mouse is over an element, even if the button isn't being held). While the button is being held, the cursor should not be able to be moved, in order to avoid accidental activations of GUI elements if the cursor is jostled at the last moment.
The benefit of this system is that it allows a user whose mouse-style cursor is over the wrong spot to avoid activating that element by just releasing the button early; the mouse-style "move away from it before you release" is less natural to accomplish on a gamepad than with a mouse, and this approach allows a gamepad user to abort an unwanted click far more easily.
We're even starting to see a few games experimenting with this cursor interaction model even when their cursor is being moved by a real mouse. No Man's Sky does this, as one example. It will be interesting to see whether this approach to handling mouse-cursor interaction will become increasingly common and expected over the coming years.