Yes, it would be okay to register components without their interfaces, but not for the reason you give.
Concrete dependencies
It may happen that components depend on concrete classes. For instance, with the Entity Framework consumers should have the ObjectContext injected into them. That's a concrete class that still needs to be injected because it should be shared between several consumers.
Thus, given a consumer's constructor like this:
public FooRepository(FooObjectContext objectContext)
you would need to configure the container like this:
container.Register(Component.For<FooObjectContext>());
The FooRepository requests no interface so it makes no sense registering an interface (even if one was available), but you must still register the concrete class because Windsor can only resolve types explicitly registered.
Interfaces with only one implementation
Then what about interfaces with only one implementation? Once again, the consumer decides the requirements.
Imagine that a consumer has this constructor:
public Ploeh(IBar bar)
The only way Castle Windsor will be able to resolve Ploeh is when you register IBar. Even if Bar is the only implementation of IBar, this will not work:
container.Register(Component.For<Bar>());
This doesn't work because IBar is never registered. Castle Windsor doesn't care that Bar implements IBar because it doesn't want to try to be smart on your behalf. You must tell it explicitly:
container.Register(Component.For<IBar>().ImplementedBy<Bar>());
This maps IBar to Bar.
Registering both interfaces and concrete types
Then what if you want to be able to resolve both the concrete type and the interface?
The problem with the previous example is that it will let you resolve IBar, but not Bar.
You can use the Forward method, or multigeneric overload of For to forward registrations:
container.Register(Component.For<Bar, IBar>().ImplementedBy<Bar>());
This lets you resolve both Bar and IBar.