Although it's not something that is described in the Scrum Guide, the concept of a Spike is pretty well known (Wikipedia, Mountain Goat Software, SAFe).
A Spike is a specific task.
Planning the Spike. Although some people say to not put them on the Product Backlog, I find it helpful for planning purposes, especially if you identify the need while performing a Backlog Refinement for items that is not slated to happen for a sprint or two - you may decide to defer the spike until the sprint before it's needed. Of course, this does break the Scrum Guide's definition of what a Product Backlog is, but I do think it's important to do what works for the team.
Estimating the Spike. You don't typically estimate spikes. You timebox a Spike. They could cross Sprint boundaries, even. Instead of estimating them, you define an objective or a scope and have it completed by a given date. However, something that may work is putting an upper bounds of effort on the Spike in terms of your units of estimation (hours, points, whatever). For example, if you use Story Points, you can put a number of Story Points on the Sprint. Whoever is working on that Spike spends that level of effort on the Spike. If it ends up being more complex, you can go into a replanning to decide how to reorder the Sprint and Product Backlogs based on this extra work. Personally, I find not estimating them and completing them within the bounds of a Sprint (to enable work on another Product Backlog Item in the next Sprint) or before the next Backlog Refinement session (to allow for estimating the Product Backlog Item) to be the most useful.
Scheduling the Spike. If you follow traditional guidance and don't estimate a Spike, you do need to consider the impact to velocity if one or more members of the development team are working on an item. Because it's work that has no estimated points or time but still has to be done (using effort and time), it will prevent you from doing other work.
Spikes are only useful for training specifically tied to the product and project at hand. Some training - compliance or regulatory training and professional development, for example - isn't necessarily tied to work done on a specific project.
These types of training should be factored into capacity. If people have training that is estimated to take a day, you should reduce your velocity appropriately (assume an extra non-working day for the members of the team who are doing the training).
These types of things should not be on the Product Backlog or in a Sprint Backlog at all and they shouldn't be estimated by the project team. They exist outside the project management methodology, but impact how the work is done.