No.
OpenGL doesn’t have “world-space”. It has object coordinates (the raw coordinates passed to glVertex, glVertexPointer etc), eye coordinates (after the model-view matrix has been applied), clip coordinates (after the projection matrix has been applied), normalized device coordinates (after division by W) and window coordinates (after the viewport and depth-range transformations).
You probably want to work in object-space, as as this makes the defining equations simpler (e.g. you can model any ellipsoid using the equation for a unit sphere, although you need to be careful about reflections in the case of non-uniform scaling). Although eye-space may be more suitable if you’re trying to ray-trace multiple objects at once.
The way I would approach it would be to pass 2D unit coordinates ((-1,-1) … (1,1)) as texture coordinates for the vertices. These are the X and Y components of the ray’s position in normalised device coordinates, where its direction is (0,0,1). Remember, in normalised device coordinates the view frustum is always the unit cube. Rays are parallel to the Z axis, and the points where the ray intersects the near and far planes are (X,Y,-1) and (X,Y,1) respectively.
In the vertex shader, take the homogeneous points (X,Y,-1,1) and (X,Y,1,1) and transform them via gl_ProjectionMatrixInverse for eye-space coordinates or gl_ModelViewProjectionMatrixInverse for object-space coordinates (or their equivalents if you’re using user-defined uniforms rather than compatibility uniforms). Store the transformed coordinates in variables which are interpolated and passed to the fragment shader.
Within the fragment shader, the variables hold the eye-space or object-space coordinates where the ray for that fragment intersects the near and far planes. The parametric equation for the array is given by linear interpolation between the two points. Note that whether you divide by W before or after interpolating affects whether the interpolant corresponds to linear depth or reciprocal depth (as with depth buffer values).
This approach has the advantage of taking the relevant matrices into account, so the results will be consistent with conventional (forward) rendering using those matrices. It will work with either orthographic or perspective projections, whereas assuming that the rays converge on an “eye position” will only work with a perspective projection. It will work with off-centre or non-aspect-preserving projections, whereas using fixed eye-space vertices won’t.