Agile is about self-organizing teams. The team is the one that can figure out the best way of doing the work, and usually, you end up with some kind of pull system. People take work, they are not assigned work.
If the team decided it's a good idea to encourage everyone to take tasks that they are not familiar with, then that's one thing. If you want a practice that discourages them to take tasks that they are familiar with, then that's another thing. The first approach is Agile, the second... I doubt so.
I don't think there is any Agile process that does what you are asking for, and that's because it doesn't really make sense unless your context is particular. By that I mean that the work is more or less from the same area of expertise, your team members have roles from within that area of expertise, but they don't just have the same experience. Some are more skilled, some are less. Doing what you suggest might work in that situation, but it can't work in all situations. And the reason is that, inevitably, you will have specialization within the team.
The way you phrased to question makes me think that you believe specialization is a problem. It isn't as long as the team has all the roles within the team to do their job, then that's no problem. Teams deliver software in Agile, not individuals.
Specialization becomes a problem when the company has silos of specialists that get shared between teams and projects. There you indeed have an issue because it's an external dependency and the team actually lacks some roles to do their job properly on their own.
It's good to share knowledge, it's good to have pair programming sessions, it's good for people to get the big picture and have shared responsibility over results, but assigning them tasks they are not familiar with is not necessarily the way to do it. It pushes them out of their comfort zone and that's a way to learn things, but push them too far and you will get a mess on your hands, end up causing a lot of frustration, and even employee turnover. Like I said, this works in certain contexts, not in all. I encourage you to think at the last project you tried this on and consider the skills of the people and the nature of the work, and I'm sure you will discover that there was not too much variation, just different levels of experience and view of the big picture.
To give you another example, consider you have a designer on your team and a Java back-end developer. Would you force a design task on the back-end developer just because you want to avoid specialization? Or worse? Would you give the designer a back-end task? It makes no sense.
There is indeed one issue: when working on priority tasks. Say the designer is busy, but the back-end developer just finished some work and can pick up the next task from the list of priorities. The next task in order of priorities is a design task. Ups! Now the developer has to look around to see what other back-end work there is. The second task is back-end work, so they pick that task up. But that was the second priority, not the first. That's a problem, right? But you don't fix this problem by shoving the design task on the throat of the back-end developer.
If you are worried about the way the work is performed or you have identified some risk with programmers picking only certain types of tasks, then bring the issue up with the team and let them figure out a way to fix it. Don't impose a certain way of working, there might be other/better ways to fix it, not necessarily like you suggest.