you don' t seem to have any simulation happening here that I can tell so no way to accumulate any movement on the points. @v = @N and so it is everafter. However you may be looking in the correct direction. There are probably a gazillion ways to do this.
Hope this may point you toward some non simulated options. You could also take this into a solver perhaps or do in a POP for time based action by adding fractions of @N to the points.
at some point, either with simulation or without you need to add the normal to the point position. this example uses a mix node and attribute transfer to get the normal data from the poly to the point.
And an alternative way to do this without a solver is to throw down a point wrangle a type in: @P = @P + @N * @Frame;
Thats it. You don't need an @v attribute to make them “move”, although now if you want to use these points “velocities” to drive something else you could throw down a trail sop after your point wrangle and set it to get v, which is just the difference in each point's position between two frames.
I say “move” because again your not simulating anything now, your just basically adding the normal of each point onto its own position, whatever that position was at frame 1. You are also scaling the normal by a variable which happens to be the frame number, but that variable could be anything.
You may want to add an addition term in the above equation to keep the points from “moving” too fast. For instance: float term = 0.1; @P = @P + @N * @Frame * term; But this is entirely up to you.