T-shaped skills mean that skills are shaped like the letter T
: deep in some places, shallow in others. That is, skills are expected to be specialized, but with some sufficient understanding of adjacent disciplines to allow for effective collaboration. There is no contradiction between T-shaped skills and specialization. T-shaped skills imply specialization.
And with that, let's take a look at the travesty that you call agile:
a software engineer can be assigned to UX design tasks in the name of agility
In agile, developers aren't "assigned" work, let alone in the name of misunderstood buzzwords. In agile, developers form a self-organizing team. That means the team discusses who should do what. If, during this discussion, somebody suggests that Peter, the experienced software engineer, do UX design tasks, Peter is likely to speak up and mention that he knows little about UX, and that it would be more efficient and effective if somebody with better UX skills did the work.
Now, it might still happen that Peter doing UX work is the best call. Perhaps the UX guys are swamped because one of them has the flu, so there isn't enough work for the software guys. But if this is a frequent occurrence, and in particular if Peter doesn't like UX work, Peter will likely speak up at a retrospective, identify this as inefficient (or annoying) and ask the team to explore ways to improve. And the team, being judged on its ability to produce working software, has a strong incentive to do so.
In short, the situation that people are assigned work they aren't qualified for, in pursuit of the management buzzword of the day, doesn't tend to occur in agile practice, because the imbalance of power that makes it hard for Peter to point out how asinine an idea this is doesn't exist within an agile team. And if the team fails at organizing work in a way that makes effective use of the available talent, agile process frameworks give teams both the incentive and the opportunity to fix this.
if one's target is to be very specialized and an expert in a single field, is agile not healthy for that individual
Depends on how specialized you want to be. An agile team has a limited size, and must encompass all skills necessary to deliver the solution, and in sufficient redundancy. This limits the number of different specializations a team can have. However, depending on the nature and size of the project, the set of skills needed may be very diverse, and specializations comparatively broad, or rather specific and comparatively narrow. For instance, if a team of 2 writes a full stack application, you likely need two "jack of all trades" devs capable of doing UX, implementing UI, business logic, database access, deployment and support. If however a team of 12 is tasked with replacing a set of webservices in a particular application domain, then database, security, business logic developer, domain expert, deployment and support may all be separate specializations. So if you want to specialize, look for big projects focused around your area of expertise.
And if you want to be extremely specialized ("the world's leading expert on this particular area of this particular framework"), it might be better to exist outside project teams, to be consulted only if they have a problem in your specific area of expertise.
(None of this is specific to agile processes, by the way. Even the most old-school waterfall project will want the team to have all the necessary skills, and insist on sufficient skill redundancy to ensure business continuity.)
The only time agile has any bearing on specialization opportunities is with misunderstood agile. Specifically, if the absence of formal hierarchies within an agile team is communicated as "everybody should be equal", but understood not with respect to the social hierarchy, but with respect to skill sets.