The ROS navigation stack provides point-to-point navigation by default. In order to use the navigation stack, you must provide sensor streams (LaserScans and/or PointClouds), odometry information, and proper transforms. In the case of GPS, the GPS unit will provide part of the odometry required for navigation. See this tutorial for setting up odometry.
The main problem here is that A) you need a nav_msgs/Odometry message. This can be obtained using the gps_common node which will convert the Lat/Long fixes into UTM (meters) and publish an odometry message for the nav_stack. The problem here, however, is that that information is insufficient for full navigation. The nav_msgs/Odometry message also requires a geometry_msgs/Twist (i.e. the velocity of the robot in 3D space). The only way to calculate velocity using a GPS is to do a time-difference of the fixes, and even then, this information does not necessarily provide you with a heading (orientation and angular velocity). GPS is good for 2D position in x-y, but not for heading or velocities of any kind.
To solve this problem, ROS provides the robot_pose_ekf node to fuse different forms of sensor data together to use the best of each sensor.
For the time being, you could use the GPS and just take a fix-by-fix difference of position to acquire your velocity and heading. I must warn you though, GPS fixes tend to be pretty jumpy. Depending on the GPS, drift can be multiple meters between readings. Typically, GPS fixes require heavy filtering to be useful.
