In general I'm going to say no. Because assuming an update without a specific revision you have a race condition. Even if you tried the update and it would have been successful the next update may fail since someone else may have committed something that created a conflict.
The update function of the Subversion client library doesn't have a way to do a dry run of an update.
However, you could handle what you want to do, though it's not going to be particularly convenient or accurate. First find out the current HEAD revision. Then do a status call with the update flag set to true and the revision you retrieved from the HEAD revision. Look to see if any of the modified files require an update. If not run your update with the revision you retrieved.
This will have false positives since some changes in the same file can be merged at update time. It'll also have some false negatives since tree conflicts may not be detected.
Even if a change merges successfully as far as Subversion is concerned during a real update it might still not be a good merge. There might be semantic conflicts (e.g. one user renames a function and another user has added another call to the function).
As a result I don't think it's really something that can be automated well.