Velocity is given in [distance units] per second, and you have a delta time in seconds (or at least you should, for all the reasons specified by Yakyb in his answer). The velocity tells you how far you want to travel in a second, so if your delta time from the previous frame is (for example) 0.1 seconds, and your velocity is 50 pixels/second, then the player should move 50 * 0.1 = 5 pixels in the new frame.
So, the simplest case would be to set your velocity to a constant value (e.g. 50), and either apply it or not based on whether the player is pushing the appropriate movement key / button / whatever:
vxMax = 50
if ([is the "move right" button down?])
player.vx = vxMax
player.vx = 0
player.x += player.vx * dt
// Ditto for player.vy and player.y
This is a good start, but it has some problems. First, movement is will be jerky -- the player will start and stop moving instantly, and always move at a constant velocity. You probably want to gradually increase the velocity from 0 up to the maximum velocity over several frames while the movement key is held, and then gradually decelerate to back to velocity=0 when the key is released.
This approach will also break down when the delta time is very large. For example, if you hit a sudden unrelated system performance hitch that causes one frame to take ten seconds to render, then your delta time will be (relatively) huge. Unless your collision detection code is very careful, this will cause the player to jump instantly across the game world, passing through any walls and obstacles in between. There are ways to avoid this; you can detect abnormally large time steps and break them down internally into several smaller time steps, checking for collisions every step of the way. Or you can look into continuous collision detection, swept-volume collision detection...but that's way beyond the scope of this question.