Yes, there are several ways for the controller to predict the trajectory of a flight. The closer the flight gets, the more precise the predictions also get.
It all begins with a flightplan. Prior to departure, a flightplan will have been sent to all ATC units expected to be involved with handling the flight. This includes an estimated time of departure (EOBT) and an estimated elapsed time (EET). Based on these, you can roughly predict when a flight will enter your airspace. The estimated time of departure in a flightplan, however, is not very accurate, since the flight is allowed to deviate from it with +/- 15 minutes.
In some cases, when the flight takes off, a departure message (DEP) will be sent to everyone who has received the flightplan. The DEP message contains an actual time of departure, which allows you (again based on flightplan data including EET) to calculate a more precise estimated time of entry into your airspace. This is still not very precise, since many different things can happen enroute that means the flight arrives some minutes earlier or later than expected.
Next step is coordination. For IFR flights, every transition from the area of responsibility of one ATC unit to the next requires prior coordination. Controllers often do this manually (via phone), but more and more systems support automatic coordination and exchange of estimates, for example via "On-Line Data Interchange" (OLDI) or other electronic message formats. You will typically receive a coordination for a flight somewhere around 5-10 minutes before it enters your airspace. The coordination will contain a precise estimate of when exactly the flight enters your airspace. The required precision for such an estimate is typically in the range of 3-5 minutes (if a delay occurs after the coordination has happened, exceeding the 3-5 minute tolerance, a new coordination has to be done). This is really the point at which the controller will start "paying attention to the flight" as you say.
Up until now, the flight has still not checked in to your frequency, but that is the next step.
When the flight calls you - assuming a radar based environment - you should be able to identify the flight on the radar. This gives you a precise location for the flight, along with current level, track and ground speed. Knowing these values lets you extrapolate the trajectory of a flight quite accurately. System complexity varies, but common for all radar systems I know is the option to show a "prediction vector". This is a vector (straight line) drawn from the radar track symbol of a flight in the direction of travel for a certain length, commonly based on the ground speed. For example, in a terminal environment, you might have 2-minutes prediction vectors enabled for all tracks, which means that, for all radar tracks, the system will draw a line indicating where the aircraft will travel in the next two minutes (assuming, and this is important, constant heading and ground speed). This is a very intuitive way to visualise for the controller both the current heading of a flight, and its speed, which is useful in many different situations. The controller usually has the option to change the look-ahead time of the prediction vector, either for all tracks or for a single flight, typically in 1-minute intervals.
The green lines shown here are prediction vectors
Note that a prediction vector only works based on current heading and ground speed. A change of either of these will change the prediction vector. There are systems that take into account the planned route of a flight when predicting the trajectory, such as Medium Term Conflict Detection (MTCD), but these are mainly used in the enroute (ACC) environment. In the terminal environment, aircraft are climbing and descending, which means they are constantly changing (ground) speed. Also, many aircraft in the terminal environment are under radar vectors, which means they are not following predefined routes, so the system has no way of knowing if and when an aircraft is going to make a turn (since this is decided by the air traffic controller on short notice). These factors make tools such as MTCD pretty much useless in the terminal environment.
There are also trajectory based safety nets, although that's not exactly what you are asking.
Short Term Conflict Alert (STCA) is used to warn the controller of possible impending losses of separation between two radar tracks. You can think of STCA as working similar to a prediction vector, the main difference being that the STCA uses a 3-dimensional vector, since vertical movement is considered as well as horisontal movement. However, just like a prediction vector, STCA only considers what the aircraft is doing right now and extrapolates that into the future. The system does not know if a flight is going to make a turn or level off in 10 seconds. Because of this, the threshold values for triggering an STCA are usually set lower that actual separation minima, to reduce the number of nuisance alerts (e.g. if the required separation is 1000 ft, an STCA might be set to trigger if the predicted separation is less than 800 ft).
There are also tools such as Minimum Safe Altitude Warning (MSAW) and Area Proximity Warning (APW/AIW) which present a warning to the controller if a flight is descending lower than a defined safe altitude or about to enter some sort of restricted airspace. For the most part though, these are based on current position and altitude of a flight, not predicted trajectory.
As for the last part of your question, no, there are no tools that tell the controller how to vector a flight. After all, that is what we are trained for and do very well. With commonly available computing power, there are simply too many variables to consider for a computer to vector and sequence aircraft as efficiently as a human controller. Although, in my opinion, it is probably just a matter of time before supercomputers can more or less take over such tasks.