I've seen a lot of different exceptions made like this in agile - called spikes, buckets, non-stories, etc. This is doable - basically it's just an allotment of time. The only place I've seen it get ugly is when you assign an huge number of story points to it to account for the time you're taking to do many tasks, then you have a substantial portion of the sprint going from in-progress to done all at once - really defeats the point of a burndown. I think if you want to do it this way, don't try to track it as story points.
That behind me, I've also seen UX and UI integrated beautifully into agile user stories. To do it, it is necessary to break the design process into it's smaller parts. I'll try an example of a login process below. It might not be perfect because I'm doing it quickly about a hypothetical interface, so try to take the idea, not the details.
I would like a low-fidelity workflow of the login process so that I understand the different ways users will interact with the interface. (tasks might include a rapid prototyping session, hallway testing, etc).
I would like a standard added to the style guide for text inputs so that developers know how to format those elements in the login page.
I would like a standard added to the style guide for button inputs so that developers know how to format those elements in the login page.
I would like a standard added to the style guide for error messages...
I would like copy determined for login messaging.
I would like to run a usability test of a high-fidelity prototype.
And so on. These are pretty granular, I know, but my experience has been that this really pays off. It helps the rest of the team and the stakeholders see what you're putting into this application and it means a lot when you're demonstrating the value that your team has delivered in the sprint - that kind of team-integration is fairly important to Agile.
Edit: I forgot to mention, breaking it down like this also helps you pick the pieces you need to deliver for the team to move forward. This avoids that situation where you're asked to do absurd amounts of work in a short period of time - and that happens a lot. I can't count the number of times I saw developers say "well, we're stuck because the UI guys isn't done yet". They're not being jerks. They're asking you to turn out a full UI and they're waiting for everything before they start on anything - they just don't understand design enough to understand what they're doing. This approach helps you work on the same terms as the rest of the team.
