Class design question
My first reaction is that your click handler is doing way too much work on its own.  You should break up the code into smaller methods to make it easier to maintain.


Move all the OpenFileDialog setup to the designer file.  This will make it a field rather than local variable, preventing unnecessary object creation when a user clicks Add multiple times.  Additionally, it will wire-up the proper Dispose call for you.
Take the code for opening the files and put it into a separate method.
Split off your worker event handlers into class methods rather than anonymous methods, better separating out method responsibilities.


Other things I would do:


Pass the filenames to the BackgroundWorker in its RunWorkerAsync(Object) overload.  This prevents synchronization issues if a user clicks add while the worker is still running.
Folowing the Single Responsibility Principle, you should move the file testing into the ListBoxFile class or some other helper class.  UI views should not typically handle I/O.
Make ListBoxFiles._files non-static.  If you want singleton behavior for some reason, you can keep a static reference to a ListBoxFiles object.  Providing instance-based methods but backing them with a static collection could be a bit jarring to callers, failing the Principle of Least Surprise.
Instead of using Stream, it may be more clear to use File.OpenRead(string).
With either Stream or File.OpenRead, you need to dispose the streams
Instead of raising an add event on ListBoxFile, you should instead data bind your list control to a BindingList&lt;T&gt;.  That will handle automatically updating your control as items are added/removed.