Treat it like you do with vacation days
If someone needs to learn some things, and they are not working on stories in the sprint, then it's like if they were on a sick leave or in a vacation. When that happens, you decrease the capacity of the team when doing your sprint planning. That means you take fewer stories in the sprint because you have less people available to do the work.
Your velocity will decrease of course, but that's not a problem because it's correlated with a decrease in capacity and not because of any actual issues with the work itself.
Another approach is to use a spike. Being a time-boxed activity, the result will be the same: less work on other stories. So it ends up just like a decrease in capacity.
Keep the training decision transparent and visible and you should be fine no matter how you handle it.
Learning task doesn't produce business value.
Yes it does. You don't learn for the sake of learning, you learn to do something with the new information or skill. To be better at your job. This will reflect in the work you do "post training". Although harder to quantify, it will bring value. Value isn't just stuff inside a user story.
It can't be timeboxed because we estimate in story points.
You have a bunch of things timeboxed in Scrum. The daily meeting, the sprint duration, the refinement meeting, etc. You need slack in the process to improve your work no matter if it's for inspecting and adapting or for training. You can't attach story points to everything, nor should you try.