Is it OK to ignore InterruptedException if nobody calls interrupt()?

Instead of swallowing it, if you're so sure it will never happen, you can crash instead of ignoring it. For example, throw an Error (or a RuntimeException):

try {    Thread.sleep(1000);} catch (InterruptedException e) {    throw new Error(e);}

From the Javadocs for Error:

An Error is a subclass of Throwable that indicates serious problems that a reasonable application should not try to catch. Most such errors are abnormal conditions.

If you think it's worth assuming something will never happen, then if it does happen, that's an "abnormal condition" that, who knows, might just be a "serious problem".

Another way to look at this is, if someone in the future does interrupt your method, is there any chance that they will want it to continue running as if nothing had happened? I would guess no.

Ignoring a checked exception is never considered to be safe.
It may be ok for you at the moment, but if another programmer extends your code, he will expect the standard behaviour: the thread reacting to an interrupt call.
Also an empty catch block is dangerous in this case, since the JVM removes the interrupted flag and it should definitely be set again with

Thread.currentThread().interrupt();

in the catch block. In my opinion, this is the minimum catch implementation for InterruptedExceptions. Checking for the isInterrupted flag in a loop doesn't hurt much, either.
It is little overhead compared to your future programmer self's hassle searching a day or two for unexpected thread behaviour as you project may have grown a bit.

If you feel that your code's readability suffers from those catch implementations, you may implement your own safeSleep utility method, which takes care of the Exceptions and sets the flag properly.

On the other hand, InterruptedException is not thrown by the JVM itself in case of a hardware failure, it is a user indicated Exception only. So, if you do not propagate your Threads reference, there won't be any other Threads that are able to call Thread.interrupt() on it. That's it technically. But you shouldn't underestimate the human factor and your programs evolution.
Edit: As ruakh pointed out, there actually is a way to get a Threads reference and thus to schedule an Thread.interrupt() call. That way the developer in heat may not even have to look at the class, that implements your uninterruptible Thread. In my opinion that's even another reason, to implement proper exception handling.
Another thing: If you're not throwing an Exception, logging such an event on a level beyond INFO may be a good choice.

You should never swallow an exception if you think that it should never occur. It’s ok to decide not to add code handling a condition which never occurs but it shouldn’t happen silently.

The minimum you should do is:

catch(InterruptedException ex) {  throw new AssertionError(ex);}

This ensures that whenever your assertion that this will never occur is wrong, you will notice. This pattern also applies to other unexpected exceptions, e.g. IOException when you know that the target OutputStream is a ByteArrayOutputStream or the Appendable of a Formatter ought to be a StringBuilder, etc.

By the way, there is an alternative to Thread.sleep not requiring to deal with InterruptedException at all:

LockSupport.parkNanos(TimeUnit.MILLISECONDS.toNanos(timeInMillis));

This method will simply return earlier when the thread has been interrupted and retain the interrupted state of the Thread so it provides already a correct handling for the case that your code is used by someone else who does use interruption (assuming that the caller of your code checks the interrupted state then).